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MESSAGING SYSTEM 

This invention relates to a messaging systenn, in particular a messaging system 
for use in the DECT (Digital European Cordless Telecommunications) system 
and other communications systems such as WCPE (Wireless Customer Premises 
Equipment) and PHS (Personal Handyphone System). The system may be used 
to provide a multipurpose messaging service that can be used for access to 
alternate data/messaging services with a common air interface structure 
accomplished with a general protocol layer defined on the top of the DECT 
protocol layers. 

One implementation of a DECT system will now be described. 

The Digital European Cordless Telecommunications (DECT) is a standard 
provided for cordless communications for both voice and data traffic. Reference 
may be had to the ETSI documents defining the system, which are incorporated 
herein by reference. A DECT system includes at least one portable part (PP) 
and at least one fixed part (FP). The PP contains all elements between the user 
and the air interface whereas the FP contains all elements between a local 
network and air interface. Thus no fixed infrastructure has been defined. The 
connection to the networks is made through interworking unit (IWU), functions 
of which are defined in the DECT profiles. 

The DECT protocol layer structure is illustrated in the figure 1 . The following 
descriptions of the layers are based on the common interface standard ETS 300 
175-1 to 9. Radio Equipment and Systems (RES); Digital European Cordless 
Telecommunications (DECT) Common interface Part 1-9. European 
Telecommunications Standards Institute 1992 thus the features described here 
form a library of services for use by different profiles. 
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DECT provides on the physical layer, in the frequency band of 1880-1900 MHz, 
10 carriers each of which are carrying 24 TDMA slots. The slots can be used 
for either bi-directional (12 slots for both directions) or unidirectional traffic 
(maximum of 23 slots for one direction). The gross bit rate is 1152 kbit/s. A 
timeslot is divided into control/signalling (4,8 kbit/s net rate) and traffic fields 
(32 kbit/s net rate). 

The medium access layer (MAC) can provide broadcast, connectionless and 
connection oriented service. The connection oriented service can be non- 
protected or protected. The protected service provides a possibility for modulo 
2 retransmisson. 

The data link control layer is divided into C- (signalling and low rate user traffic) 
and U-planes (user traffic). The U-plane can provide the following services for 
the upper layer application: LU1 transparent unprotected data (for voice), LU2 
frame relay (data), LU3 frame switching (LU2 with LAP protocol for data), LU4 
forward error correction (data), LU5 and LU6 rate adaptation for V.1 10 traffic. 
In addition LU7 is defined in the DECT/ISDN interworking profile to provide 
services for ISDN traffic. 

The network layer on the C-plane contains the following services: Call Control 
(CC) used for call establishment and maintenance, mobility management (MM), 
call independent supplementary service (CISS) used for supplementary services, 
connection oriented message service (COMS) is an acknowledgment service 
used for transportation of limited amount of user data and Connectionless 
message service (CLMS) used for broadcast or point to point connectionless 
traffic. Call related supplementary services (CRSS) are related to a CC call and 
it provides a specific keypad protocol for the service management. The U-plane 
does not have a network layer. 
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According to a first aspect of the present invention there is provided a 
messaging system for communicating a message between a first 
communications unit having a first messaging entity and a second 
communications unit having a second messaging entity, each messaging entity 
comprising: a messaging call control means for establishing a messaging 
communications link with the other messaging entity; and a messaging means 
for, once the messaging communications link has been established, exchanging 
messaging information with the said other messaging entity. 

Preferably, the messaging entity constitutes a virtual layer between the 
application layer and the network layer of the communication protocol. 

The messaging information suitably includes header data and user data 
associated with the message. The header data and the user data suitably 
include data defining a message sequence number of the message. The header 
data and the user data are preferably carried by different communications links. 
Most preferably one link operates through a C-plane and the other link operates 
through a U-plane of a communication protocol. 

The messaging system suitably operates according to the DECT, WCPE or PHS 
protocols. One of the communications units may be a portable part and the 
other is a fixed part. Alternatively, one of the units may be an intermediate 
server unit. One of the communications units may be provided with an 
interworking unit for performing protocol conversion. 

According to the present invention from a second aspect there is provided a 
messaging method for communicating a message between a first 
communications unit and a second communications unit, the first 
communications unit having an application layer, a messaging entity and a 
network layer, the method comprising the steps of: transmitting a signal from 
the application layer to the network layer as a means of establishing a call; 
exchanging messaging information between the application layer and the 
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network layer by way of the messaging entity to communicate the message; 
and transmitting a signal from the application layer to the network layer as a 
means of disconnecting the call. 

According to the present invention from a third aspect there is provided a 
messaging method for communicating a message between a first 
communications unit and a second communications unit, the first 
communications unit having an application layer, a messaging entity and a 
network layer, the method comprising the steps of: transmitting a signal from 
the messaging entity to the network layer as a means of establishing a call; 
exchanging messaging information between the application layer and the 
network layer by way of the messaging entity to communicate the message; 
and transmitting a signal from the messaging entity to the network layer as a 
means of disconnecting the call. 

In the messaging system/method commands can preferably be sent between 
messaging entities of each communications unit. The commands preferably 
include MMS SEND, MMS RETREIVE, MMS-RETREIVE-RPY, MMS COMMAND, 
MMS-COMMAND-RPY and MMS STATUS. 

A messaging entity can preferably request a reply from the other messaging 
entity or an end entity. The said header data is preferably conveyed in one or 
more DECTA/VCPEAA/LL call control information elements and most preferably in 
one CC message. 

The messaging system/method preferably includes any or all aspects of the 
up/downgrading, the service negotiation and the interworking procedures and 
the < < BASIC-SERVICE > > element described below. 

The present invention suitably relates to a system for, for instance, providing 
teleservices for FAX and short message (such as GSM SMS) transfer. This may 
suitably allow for GSM interworking and also, generally, may extend the 
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capabilities of DECT systems. In the future the demand for data messaging may 
also expand to other teleservices/data services (such as Internet based 
messaging/file transfer) and the present invention may preferably provide for 
this too. Employing a preferred embodiment of the invention a DECT system 
may expand from a cordless telephone system into a multipurpose information 
system with a wide variety of information services. At the same time it may 
offer also basic voice traffic and hence widen the possibilities for DECT service 
providers and manufacturers. 

The present invention suitably provides a messaging service for a DECT system 
which can provide a wide variety of network services with a single new 
protocol layer compared to prior art DECT systems. In this way a simple and 
cheap portable terminal with wide variety of messaging/data services may 
suitably be provided for users. The protocol preferably contains a general set of 
minimum functionality for all alternate services, because the services contain 
such a wide variety of different options that it may conceivably be difficult to 
accomplish all functions of different services at the same time while maintaining 
a low level of complexity of a protocol. 

The new protocol layer will be referred to as a multipurpose messaging service 
(MMS). The MMS protocol may preferably provide for general interworking to 
multiple information services such as T.61 1 Fax, GSM SMS, CCITT X.400 and 
internet HTTP. 

The protocol may preferably be usable by both short messaging and fax/file 
services. The principal difference between these type of services is in the 
transmission capability: the short messaging preferably uses only the control 
channel (C-plane) for MMS signalling and user data transfer whereas the fax/file 
service preferably uses the traffic channel (U-plane) for user data and control 
channel (C-plane) for MMS signalling. This type of structure can suitably 
provide a flexible service. That is, a U-plane bearer service (C.2 data profile) 
can suitably be upgraded into fax/file transfer -teleservice by adding the MMS 
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protocol on it. Also short messaging (E profile) can suitably be upgraded to a 
fax service by adding the U-piane service to the short messaging. Downgrading 
is preferably also possible. These procedures can suitably be done during 
already established connection as illustrated in figure 2. This procedure can be 
utilized for instance by sending the user a short message indicating that a fax is 
arriving. The user can, if he is capable to receive the fax, upgrade his short 
message connection into a fax capable high speed service to receive the fax. 

Since the prior art DECT air interface typically supports only a limited service 
negotiation capability, the present invention preferably also provides for a new 
flexible service negotiation, suitably by adding new elements to some DECT 
messages. In this way the service negotiation may suitably be more flexible and 
some interworking unit/network service parameters may suitably be 
negotiated/changed even during call establishment. Also a new coding of the 
DECT IWU selection (< <iwu-attributes> >) element may preferably be used to 
provide more general coding to IWU service selection. This may help to 
overcome the problem that prior art DECT coding is only ISDN oriented and 
does not fit well into general data service selection. The new coding is 
preferably backwards compatible with the old coding. 

Aspects of the present invention may help to provide the following advantages: 

• allowing a wide set of services to be accessed in a standardized simple way; 

• providing relatively simple terminal applications, so the terminals can be 
simple and cheap; 

• providing an up/down grading procedures allowing a user friendly flexible 
service system to be implemented; 

• allowing expansion of the DECT systems and terminals for future data 
services; 

• minimizing the changes required in the DECT protocol layers 

• keeping close to the GAP DECT general voice profile, reducing the changes 
required in standard DECT terminals 
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Processing aspects of the present invention may suitably be provided by 
appropriate software operating under the control of a processor in a fixed or 
portable part. 

The present invention will now be described by way of example only, with 

reference to the accompanying schematic drawings, in which: 

Figure 1 shows DECT layers and services; 

Figure 2 shows the upgrading/downgrading procedures; 

Figure 3 shows MMS definitions; 

Figure 4 shows MMS API relations; 

Figure 5 shows MMS interaction half API and non-API cases; 
Figure 6 shows MMS interaction full API case; 
Figure 7 shows MMS internal structure; 
Figure 8 shows modeling; 

Figure 9 shows the complete MMS layer structure; 

Figure 10 shows the full-API MMS model; 

Figure 1 1 shows the half-API MMS model; 

Figure 12 shows the non-API MMS model; 

Figure 13 shows the MMS general functional model; 

Figure 14 shows the horizontal functions related to MMS messaging; 

Figure 15 shows MMS implementation for E and F profiles; 

Figure 16 shows the MMS action relations; 

Figure 17 shows MMS send action options; 

Figure 18 shows MMS retrieve action options; 

Figure 19 shows MMS Command action options; 

Figure 20 show MMS Status action options; 

Figure 21 shows MMS SETUP and CONNECT actions; 

Figure 22 shows MMS RELEASE action; 

Figure 23 shows MMS implementation for E and F profiles; 

Figure 24 shows the upgrading/downgrading procedures; 

Figure 25 shows outgoing MMS call; 

Figure 26 shows incoming MMS call; 
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Figure 27 shows the BASIC-SERVICE information element; 
Figure 28 shows the CALL-ATTRIBUTES information element; 
Figure 29 shows the IWU-ATTRIBUTES information element; 
Figure 30 shows the FACILITY information element; 
Figure 31 shows the CALLED-PARTY-NUMBER information element; 
Figure 32 shows the ALPHANUMERIC information element; 
Figure 33 shows the SERVICE-CHANGE-INFO information element; 
Figure 34 shows the FEATURE-ACTIVATE information element; 
Figure 35 shows the FEATURE-INDICATE information element; 
Figure 36 shows the IWU-TO-IWU information element; 
Figure 37 shows the CC-INFOrmation message; 
Figure 38 shows MMS and GSM SMS interworking; 
Figure 39 shows MMS and GSM Facsimile 3 interworking; 
Figure 40 shows MMS and PSTN Facsimile 3 interworking; 
Figure 41 shows MMS and Internet HTTP interworking; 
Figure 42 shows MMS and Internet FTP interworking; 
Figure 43 shows MMS and X.400 interworking; 

Figure 44 shows DECT MMS and GSM SMS transparent interworking; 

Figure 45 shows extended exchange attributes negotiation in the case of 

outgoing call; and 

Figure 46 shows extended exchange attributes negotiation in the case of 
incoming call. 

The MMS definitions and the MMS functional model will first be defined and 
concepts relating to the MMS, its architecture, basic functionality and the 
relationship of the MMS to the DECT protocol layer model and to the outside 
networks will be clarified. 

The horizontal MMS model defined below specifies the position of the MMS and 
the MMS entities in relation to the outside networks and in DECT physical and 
logical entities (FPs, PPs and IWUs). The architecture section below defines the 
MMS virtual layer internal structure. The functions section below defines the 
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functionality of the MMS virtual layer. Full-API, half-API and non-API models are 
also clarified below. 

The vertical MMS nnodel defined below specifies the position of the MMS to the 
DECT layer structure: to the DECT network layer (NWK) and to the 
application/lnterworking Unit (IWU). 

The following bullets give a general view of the MMS functions, its advantages 
and its properties. 

• MMS is a generic set of commands and information elements for 
file/messaging service. 

• MMS provides a generic file handling/messaging services over the DECT air 
interface by utilizing the DECT transportation mechanism in the best way 
possible at the same time offering a general set of functions to the 
applications using its services. 

• MMS provides a compact subset of functions to information servers with the 
advantage that a single terminal with MMS support can use a wide variety 
of information and messaging services with minimum amount of application 
layer complexity. If a complete set of services is needed an escape sequence 
has to be used or some other means such as transparent protocol 
transportation mechanism are needed. 

• MMS is in fact a DECT messaging service with wide selection of data types. 
It is very much like GSM SMS with wider variety of data types and 
operations without the length limitation of the messages. Thus MMS 
provides GSM SMS SM-TP layer services as a subset of its functions. 

• MMS is not a real protocol layer in the terms of OSI model but it is a virtual 
layer which utilizes the services of the DECT Call Control entity. It could be 
regarded as a supplementary service type of service that provides 
signalling/control and application specific information related to the 
teleservices provided by the DECT data profiles. MMS messages are part of 
the DECT Call Control messages and are accessed through the CC 
primitives. 
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• For the MMS and data profiles utilization an Application Programming 
Interface (API) can be used to provide an application independent interface. 
This interface provides a standard set of a primitives for MMS messaging. 
However, even though the application see the MMS as protocol layer when 
using the API access points the MMS is only utilizing the CC entity functions 
with some added features. 

• MMS itself is a stateless virtual protocol which defines a set of framing rules 
and information elements each containing optional and mandatory 
information fields. 

• MMS can be regarded as a non-existent protocol layer. That is, it does not 
have to exist in real DECT protocol layer structure. However, it is treated in 
this context as a real (virtual) protocol layer for clarifying the concepts, 
functions and vertical interactions in the protocol structure. 

The MMS horizontal definitions (i.e. the relations of the messaging service to 
the outside networks as well as the different DECT MMS and outside (IWU) 
network entities) will now be defined. Figure 3 illustrates some of the MMS 
definitions. 

Portable MMS Entity: Portable MMS Entity is the PP. 

Fixed MMS Entity: Fixed MMS Entity is the FP with Interworking Unit (IWU). 

MMS entity: Portable MMS Entity or Fixed MMS Entity, an entity with MMS 
messaging capabilities 

MMS action: MMS actions take place between MMS entities. The actions 
provide means for message and file transfer or retrieval between these MMS 
entities. Also a set of controlling actions are available for the remote 
transactions focused into a MMS message/file stored/handled by the Message 
Control Entity. The Message Control Entity may send status information data as 
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a response to a control action or to a specific request set by other MMS 
actions. 

Message Control Entity: The Message Control Entity is a server that is 
responsible for the controlling of the message sent by a MMS entity or the End 
Entity. It can be either the intermediate server or fixed MMS entity. The 
Portable MMS entity can control the messages in the Message Control Entity 
i.e. request the status, cancel the message forwarding etc. Also the portable 
MMS entity may be a Message Control Entity. In this case the Fixed MMS 
Entity or the intermediate server can control the message in the Portable MMS 
Entity. After the Message control entity has finished its transaction (forwarding 
the message) the message cannot be controlled anymore. In this case only 
status information regarding the message can be requested from or sent by the 
Message Control Entity. 

Intermediate server: An optional intermediate server can be in the messaging 
network. This Intermediate server is on the other side of the Fixed MMS Entity 
IWU i.e. in the interworked network. The protocol between the Fixed MMS 
Entity and the intermediate server may be selected by the MMS (primary IWU 
conversion) as well as the protocol between the intermediate and the End Entity 
(secondary IWU conversion). The selection of these protocols can be left to the 
Message Control Entity and/or to the Fixed MMS Entity. The intermediate server 
could be a GSM Short message service center (SO or a Fax server in LAN 
environment. With MMS the message/file processing taking place in the 
intermediate server can be controlled. In this case the intermediate server is the 
Message Control Entity. If no intermediate server address is defined then the 
Fixed MMS Entity is the Message Control Entity. 

End entity: The End Entity is the final object of the message transfer. It does 
not necessarily understand MMS messaging i.e. the Fixed MMS Entity (primary 
IWU conversion) or the intermediate server (secondary IWU conversion) may do 
protocol conversion according to the requests set in the MMS messages. The 
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End Entity can also be another MMS entity, for instance, the Fixed MMS Entity 
can forward a MMS message to another the Portable MMS Entity. In this case 
the Fixed MMS Entity is Message Control Entity. 

MMS addressing: MMS protocol provides addressing for the intermediate server 
and End Entity. The intermediate server address is provided during the MMS 
call establishment to define the intermediate server as a Message Control 
Entity. If no address has been defined the fixed MMS entity is the Message 
Control Entity. The End Entity address is sent in MMS actions. If no End Entity 
address is present then the message is processed by default by the Message 
Control Entity. 

Primary IWU conversion: The protocol conversion done in the Fixed MMS Entity 
according to the request of the MMS action or spontaneously according to 
interworking requirements. 

Secondary IWU conversion: The protocol conversion done in the intermediate 
server according to the request of the MMS action that is converted to a action 
in the Fixed MMS entity or spontaneously according to interworking 
requirements. 

The functionality of the MMS will now be described. In general the MMS 
functions as a stateless protocol. The full API protocol model defines the 
internal structure of the MMS API and the MMS virtual layer when the call 
control interactions are done by the MMS part itself directly according the rules 
defined in the interworking definitions. The half and non-API protocol models 
define how the MMS API or non-API primitives are used to control the MMS 
call and send MMS messages according to the definitions done in the service 
interworking definitions (see figure 4). 
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In half-API and non-API models the only task of the MMS is to packetize the 
information received from the application. The MMS standard frame format 
contains MMS specific information. After framing the MMS requests the 
network layer to transport the frames over the air interface. MMS layer may 
provides primitives for call control and MMS transportation to the application 
layer and the entity uses NWK primitives. In this case it is a half API interface 
(i.e. MMS does only framing) and in fact the call control primitives it offers to 
the application are network layer primitives. The other option, the non-API, is to 
define MMS as a set of information elements and framing rules. In this case the 
application will use directly the network layer primitives for call establishment, 
control and release and there are no MMS primitives. In this case MMS is only 
an addition of the CC or COMS entity (i.e. not more than a new set of 
information elements). The procedures relating to call control behavior are done 
in the interworking definitions. Thus the application becomes more complex. 

Figure 5 shows the following instructions: 1. Call establishment; 2. 
Message/file transfer (with MMS framing); 3. Link suspend/resume (optional); 4. 
Response received; and 5. Call disconnect. The features of the models are 
listed below. 

Haif-API model: 

• API primitives available to the upper layer 

• MMS is a set of framing and messaging rules 

• stateless 

• the application controls the call control through API primitives 
Non-API model: 

• DECT NWK primitives used by the upper layer 

• MMS is a set of framing and messaging rules, the application fulfills these 
rules for its own purposes 

• stateless 

• the application controls the call control directly through the NWK primitives 
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Some potential advantages and disadvantages of this protocol model are: 

• MMS is a part of CC or COMS entity thus no additional protocol layer 
structure has to be defined into DECT standard 

• the MMS definition is easy i.e. it is only a set of framing rules and 
information elements 

• the call establishment procedures can be built into the application or 
interworking annex. This is important since the procedures vary from 
application to application. 

In the full-API model the MMS is a protocol layer with only few primitives such 
as MN-MMS-SEND.Req, MN-MMS-FETCH.Req or MN-MMS-SEND-RPY.Ind. The 
call establishment is solely the matter of MMS layer (i.e. it establishes a call and 
sends the data by using Network layer primitives). The rules for MMS 
functionality are different in different cases of interworking service: i.e. the 
requirements of FTP are different to GSM SMS. The MMS information general 
descriptions are done in the general definitions and the required behavior of the 
MMS with network layer is defined in the interworking annexes to different 
services. Thus the complexity is moved from the application to MMS. In this 
case MMS is a full Application Programming Interface (API) that provides a 
standard access point for the applications. 

Figure 6 shows the following interactions: 1. Call establishment; 2. 
Message/file transfer; 3. Link suspend/resume (optional); 4. Response received; 
and 5. Call disconnect. The features of the model are listed below. 

Full-API model: 

• limited set of API primitives available to the upper layer 

• MMS is a set of framing and messaging rules 

• stateless or states 

• the MMS controls the call control using NWK primitives 
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Some potential advantages and disadvantages of this protocol model are: 

• A question raises whether MMS is part of DECT network layer or the 
interworking unit or a new protocol layer. The latter may imply a change in 
the structure of DECT 

• The application remain simple, however, it is possible that the MMS behavior 
varies from application to application. Thus in each service interworking 
annex the MMS call control would have to be defined. This lowers the level 
of flexibility. 

The MMS virtual layer internal architecture will now be defined in general 
terms. 

The MMS entity is divided into two separate parts: the call control entity (C- 
MMS) and the messaging entity (M-MMS). The structure is illustrated in figure 
7. The C-MMS and M-MMS detailed functionality is service/application 
dependent and is described in the specific interworking descriptions. 

The MMS messaging part provides means to the upper layer (application/IWU) 
to send and received MMS specific messages with MMS specific information 
between two horizontal MMS entities. The M-MMS part can only function if 
either the C-MMS part has established a connection between the horizontal 
entities according to the request of the M-MMS or the upper layer entity. M- 
MMS may provide a set of primitives to the upper layer or not. It contains MMS 
messaging framing rules and those rules may be either utilized by defining a set 
of primitives or the application itself may fulfill these framing/message contents 
rules when utilizing the MMS services. That is, in the former case DECT 
provides a standard MMS application programming interface {full or half MMS- 
APl) to the upper application. In this case M-MMS-SAP exists. In the latter case 
DECT provides standard rules for MMS messaging to the upper layer 
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applications. In this case DECT CC primitives are directly used and no M-MMS- 
SAP exists (non-API). 

•The M-MMS may control optionally the C-MMS part of the MMS entity by using 
as the access point the M/C-MMS-SAP point which is a service access point 
defined in between MMS virtual layer parts. The functionality of the M-MMS 
towards the C-MMS entity may be defined in the service/application 
interworking definitions. This is the full API model.. 

The M-MMS part can be itself divided into two parts: User data and User 
control data parts. 

User data part provides the functionality to convey the pure data the user 
(application) wants to transmit i.e. a fax image data, the short message text 
etc. 

User control data part provides the functionality to convey the additional 
control data that is combined into the MMS message such as control 
information to the server, time stamp information, recipient address, response 
request. 

The MMS Call Control Part establishes a connection between two horizontal 
MMS entities according the request of either the upper layer entity (application 
or IWU) or the M-MMS part. It forwards the call control requests to the lower 
layers. The C-MMS-SAP may exist on the upper interface. C-MMS-SAP defines 
the required inforrriation for call establishment. However, it exists only in the 
case the MMS-API has been defined into the MMS. Another option is that the 
upper layer (application/IWU) fulfills the connection control requirements 
defined in the DECT interworking profiles. This is the half API or non-API model. 

The optional M/C-MMS-SAP resides between M-MMS and C-MMS parts. Thus it 
cannot be accessed by the application and it is not a part of the MMS-API. It is 
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a C-MMS service access point and provides part of the C-MMS-SAP prinnitives 
directly to the M-MMS part. The M-MMS part usage of the M/C-MMS-SAP is 
defined in the interworking definition which is specific to a service to be 
interworked. The upper layer application cannot control connpletely the call is 
the case of the M/C-MMS-SAP usage. That is, the M-MMS is in this case 
responsible of the call establishment and release. The link suspension and 
release may be requested by the application. This is the full API model. 

The MMS vertical relations (i.e. how it interacts its functionality with the upper 
and lower protocol layers) will now be defined. 

The vertical model defines a (full and half) MMS-API, and a non-API interfaces 
to the application/interworking. The API provides a standard set of primitives to 
the upper layers. The non-API defines the rules/primitives of the CC entity for a 
standard set of MMS actions. 

In order to provide full functionality the interworking of the protocol has to be 
defined to both directions: up to the application/interworking unit and down to 
the DECT layers. The following chapter defines the interworking definitions and 
the chapter following that defines the functionality of the DECT upper layers 
with MMS (see figure 8). 

MMS-API layer is a completely optional feature and it is intended to provide a 
standard application interface to the application and interworking units (IWU) 
exploiting the MMS services and facilities. It provides two services access 
points (SAPs) to the upper layer. These access points are defined below. The 
MMS-API and MMS internal structure has been illustrated in figure 9. 

The M-MMS-SAP resides on the MMS-API, thus it is applicable for the upper 
layer application. M-MMS-SAP is intended for requesting MMS message 
transportation or reception. If the feature of providing control between the 
MMS parts (the M/C-MMS-SAP) is present and the interworking description 
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defines its functionality, the MMS action initiated by primitives through the M- 
MMS-SAP takes care of the call control functions. That is, no C-MMS-SAP call 
establishment primitives have to be used for call establishment. This is the full 
API protocol layer model and it is illustrated in figure 10. 

In the case of half-API model the MMS connection control has to be done by 
the upper layer application directly utilizing the C-MMS-SAP primitives. The 
half-API model is illustrated in figure 1 1 . 

The C-MMS-SAP resides on the MMS-API, thus it is accessible for the upper 
layer application. The C-MMS-SAP primitives are used for MMS call control 
directly by the upper layer application. In the case of M/C-MMS-SAP usage the 
set of the primitives is limited and the main control of the call is done by the M- 
MMS part as defined in an appropriate service interworking definition. 

The non-API interface defines how the DECT Call Control primitives can be 
utilized by the application/interworking unit directly in order to facilitate MMS 
actions. Thus no standard MMS-API interface is provided. This type of action 
takes place on the lower layer of the MMS-API plane. The non-API model has 
been illustrated in figure 12. 

The relations of MMS towards the DECT Network Layer is as the non-API 
model. Thus the interface between the MMS virtual protocol layer is defined as 
a set of rules how the DECT NWK and DECT U-plane DLC primitives are used 
for MMS call control and MMS messaging. This is applicable for all half, full and 
non-API models. 

M-MMS uses DECT Call Control messaging and information elements and DECT 
U-plane DLC layer for the MMS messages transfer. Thus M-MMS uses the Call 
Control and U-plane services. 
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C-MMS uses the normal DECT Call Control procedures for call establishment, 
suspension, resumption and release. Thus C-MMS is the same as the DECT 
Call control entity. 

The MMS relations according to the horizontal model (i.e. how the MMS 
protocol relates through the vertical model to Portable MMS entity. Fixed MMS 
entity with Interworking Unit, Intermediate server and outside network) will 
now be defined. The general model containing elements from both models is 
illustrated in figure 13. In the figure the Interworking function in fixed MMS 
entity is defined optionally, since the message control entity can be also in the 
Fixed MMS entity. The functions in the figure are in the End Entity dependent 
on the accessed service. 

Figure 15 illustrates a general MMS horizontal functional model. It should be 
noted that the procedures in the figure are not MMS actions but basic functions 
required for reaching the interworking services. Those procedures that have 
been drawn with dotted lines are optional i.e. these are not required by all 
services. A procedure is part of a MMS action, either C-MMS or M-MMS, thus a 
MMS action consists of MMS procedures defined here. Each procedure is 
defined next with a reference to the figure 14. 

Procedure 1. Establish a radio link. This is a C-MMS procedure. The purpose is 
to establish a DECT radio link with MMS capabilities. 

Procedure 2. Select IWU. This is part of a C-MMS procedure. The purpose is to 
select the Interworking Unit in the Fixed MMS entity in order to facilitate the 
required message mappings and access to the requested service. 

Procedure 3. Select a server. This an optional C-MMS procedure. In some cases 
the intermediate server is accessed through a network the Fixed MMS entity 
provides access. This procedure is used to defined the server with identification 
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{for instance, internet address, GSM SMS SC number etc.). If the fixed entity 
provides the service then this procedure is not needed. 

Procedure 4. Connect to server. This is an optional C-MMS procedure. The 
connection is established through the network into the server. 

Procedure 5. Login to server. This is a M-MMS procedure. In some cases a 
login procedure by user or application is required to reach access to the service 
provided by the server. For instance, in the FTP services case. 

Procedure 6. Select 2nd IWU. This is a M-MMS procedure. The purpose is to 
select the Interworking Unit in the Intermediate server in order to facilitate the 
required message mappings or to reach required service. 

Procedure 7. Send a message. This is a M-MMS procedure. This procedure is 
the actual message that is sent to the server for processing. Depending on the 
service either the server replies itself or forwards the message and then replies. 

Procedure 8. Receive server response. This is a M-MMS procedure. The server 
has sent a response to the previously sent message. 

Procedure 9. Receive end entity response. This is a M-MMS procedure. The 
server may send a response received from the end entity to the MMS portable 
entity. 

Procedure 10. Disconnect from server. This is a M-MMS procedure. This is a 
procedure used to disconnect the connection to a server residing in a network 
(for instance, in internet). 

Procedure 11. Disconnect from Fixed entity. This is a C-MMS procedure. This is 
a procedure used to disconnect the air interface. 
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A set of consecutive procedures can be combined into a single C- or M-MMS 
procedure. For example, procedures 1 (establish a radio link) and 2 (select Is 
IWU) can be done with CC-SETUP message. 

The MMS is utilized by the DECT data profiles E (Low rate messaging service) 
and F (Multimedia Messaging Service). It should be noted that even though the 
MMS protocol and F profile have the same name they are not the same. The F 
profile will only contain the MMS protocol definition but it will contain also 
definitions how the DECT U-plane is used for the data transmission (see figure 
15). 

The Low Rate Messaging Service (LRMS, E data profile) will use the MMS for 
short message transfer. In this case the User data and user control data is 
conveyed through the M-MMS part. The C-MMS part is used for call control. 

The Multimedia messaging service (F data profile) will use the MMS for high 
speed data transfer. The User data is conveyed through the U-plane using LU3- 
SAP and the user control data is conveyed using M-MMS part. C-MMS part will 
take care of the Call control. 

The MMS consists of different actions related to message/file handling. Not all 
actions are required in order to interwork to a specific interworking services i.e. 
a minimum subset of the following actions and information elements of the 
messages can be selected in order to facilitate interworking. However there is 
no limitation to implement all of them in addition to the minimum required set. 
The actions are defined as application layer information. The action information 
contents is divided into M-MMS and C-MMS actions/primitives by the content 
of the actions (see figure 16). 

The MMS SEND action is meant for data (message) transfer (sending) in both 
directions i.e. PP to FP and FP to PP. The reply is an optional feature and it can 
be requested by a specific field in the MMS-SEND message (see figure 17). 
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The following table shows the MMS-SEND message contents. 


Field in MMS-SEND 

Status 

Comment 

USER CONTROL 
PART 



Action type 

M 

Distinguishes MMS actions 

Reply request 

M 

Is a reply requested for the action 

<;paiJGnce 
number 

M 

A sequence number to distinguish 
MMS messages NOTE 1. 

Service type 

M 

Defines the interworking 
service/network 


O 

Defines the subtvne of the service 

transmission type 

M 

Defines messaging specific 
information 

Data content type 

M 

The upper layer (application) protocol 
of the interworking protocol (subtype 
of the service) 

Time Stamp 

0 

When message was sent 

Recipient address 

M/0 

The address of the recipient 

Sender address 

M/0 

The address of the sender 

Segmented info 

0 

Contains segmentation information 

USER DATA PART 



Character type 
coding 

M 

The data type in the user data field 

Character set coding 

M 


Language coding 

0 

Language of the message 

User data length 

M 

The length of user data field. 
NOTE 1 . 
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User data 

M 

The user data defined in Data type 



field 


NOTE. The MMS sequence number can be duplicated to both parts user 
control and user data parts when the message content is splitted 
between two data flow paths. This numbering is used to combine the 
data again in the IWU. The length also. 

The following table shows the MMS-SEND-RPY message contents 


Field in MMS-SEND- 
RPY 

Status 

Comment 

USER CONTROL 
PART 



Action type 

M 

Distinguishes MMS actions 

MMS sequence 
number 

M 

A sequence number to distinguish 
MMS messages 

Action result 

M 

Result of the action 

Control data length 

O 

Indicates if escape data is present 

Control data 

0 

Escape field for application specific 
commands 


The MMS-RETRIEVE action is meant for data (message) retrieval for both 
directions i.e. PP to FP and FP to PP. The reply containing the information 
retrieved is carried in MMS-RETRIEVE-RPY message (see figure 18). 


The following table shows the MMS-RETRIEVE message contents 
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Field in MMS- 
RETIREVE 

Status 

Comment 


USER CONTROL 
PART 




Action tvDe 

M 

Distinguishes MMS actions 


Reply request 

M 

Is a reply requested for the action 
In this case the reply is always 
requested 


MMS seauence 
number 

M 

A sequence number to distinguish 
MMS messages 


Service tvoe 

o 

Defines the interworking service, 
used for message selection 


Intermediate 
server address 

O 

The address of the optional 
intermediate server 


MMS sequence 
number 

M 

The message number for 
requested message 


Data content tvoe 

o 

The user data type 


Command type 

o 

The operation to be done to the 
message in the service after 
successful retrieval 


following table shows the MMS-RETRIEVE-RPY message contents 


Field in MMS- 
RETRIEVE-RPY 

Status 

Comment 

USER CONTROL 
PART 



Action type 

M 

Distinguishes MMS actions 

MMS sequence 
number 

M 

A sequence number to distinguish 
MMS messages (this action) 
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Service type 

M 

Defines the interworking service used 

Network address 
(address type) 

M 

The address of the recipient or sender 

Message 

transmission type 

M 

Defines messaging specific 
information 

Data content type 

M 

The upper layer (application) protocol 
of the interworking protocol 

Action result 

M 

Result of the action 

MMS sequence 
number 

M 

The message number for requested 
message 

Time Stamp 

O 

When message was sent 

Segmented info 

O 

Contains segmentation information 

USER DA TA 
PART 



Character type 
coding 

M 

The data type in the user data field 

Character set 
coding 

M 


Language coding 

O 

Language of the message 

User data length 

M 

The length of user data field. 
NOTE 1 . 

User data 

M 

The user data defined in Data type 
field 


Note: If the action was successful the requested data is in the User data field. 

MMS COMMAND action is meant for server control information transfer. With 
this functionality information stored/processed in the remote end can be 
controlled remotely (for instance, a status information can be requested or 
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message scheduled for sending can be canceled). The control reply (MMS- 
COMMAND-RPY) is an optional reply requested with a specific field in the 
MMS-COMMAND message (see figure 19). 

The following table shows the MMS-COMMAND message contents 


Field in MMS- 
COMMAND 

Status 

Comment 

USER CONTROL 
PART 



Action type 

M 

Distinguishes MMS actions 

Reply request 

M 

Is a reply requested for the action 

MMS sequence 
number 

M 

A sequence number to distinguish 
MMS messages 

Service type 

0 

Defines the interworking service used 

Time Stamp 

M 

When message was sent 
(in status information) 

Intermediate 
server address 

0 

The address of the optional 
intermediate server 

Data content type 

M 

The upper layer (application) protocol 
of the interworking protocol 

Command object 

M 

The command object number (MMS 
sequence number) 

Command type 

M 

The operation 

Escape 

commands/inform 
ation present 

M 

Indicates the presence of an application 
specific command in user field 

Control data 
length 

M 

Indicates if escape data is present 
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Control data 

0 

Escape field for application specific 



connmands 


The following table shows the MMS-COMMAND-RPY nnessage contents 


Field in MMS- 
COMMAND-RPY 

Status 

Comment 

USER CONTROL 
PART 



Action type 

M 

Distinguishes MMS actions 

MMS sequence 
number 

M 

A sequence number to distinguish 
MMS messages 

Time Stamp 

0 

When message was sent 

Command object 

M 

The command object number 
(MMS sequence number) 

Command type 

O 

The operation 

Action result 

M 

Result of the action 

Control data 
length 

M 

Indicates if escape data is present 

Control data 

O 

Escape field for application 
specific commands 


MMS STATUS action is meant for messaging control information transfer. With 
this functionality a status information can sent independently of the pervious 
requests. The status reply (MMS-STATUS-RPY) is an optional reply requested 
with a specific field in the MMS-STATUS message. This message never 
contains user information. It can be used for informing waiting messages/files in 
server. In this case the message may contain detailed information about the 
message (see figure 20). 
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The following table shows the MMS-STATUS message contents 


Field in MMS- 
STATUS 

Status 

Comment 

USER CONTROL 
PART 



Action type 

M 

Distinguishes MMS actions 

Reply request 

M 

Is a reply requested for the action 

MMS sequence 
number 

M 

A sequence number to distinguish 
MMS messages 

Time Stamp 

M 

When message was sent 
(in status information) 

Information type 

M 

The operation 

Action result 

M/O 

Result of the action 

Command object 

0 

The number of the message the 
action is referring to (MMS 
sequence number) 

Sender address 

0 

The address of the sender 

Service type 

0 

Defines the interworking 
service/network 

Service subtype 

0 

Defines the subtype of the service 

Data content type 

0 

The upper layer (application) 
protocol of the interworking 
protocol (subtype of the service) 

Message length 

0 

The length of the message waiting 
in server 


The following table shows the MMS-STATUS-RPY message contents 
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Field in MMS- 
STATUS-RPY 

Status 

Comment 

USER CONTROL 
PART 



Action type 

M 

Distinguishes MMS actions 

MMS sequence 
number 

M 

A sequence number to distinguish 
MMS messages 

Action result 

M 

Result of the action 


The following table shows the Information elements in M-MMS actions 


Element 

Values 

Length 

Comment 

Action 
type 

MMS-SEND 

MMS-SEND-RPY 

MMS-RECEIVE 

MMS-RECEIVE-RPY 

MMS-CONTROL 

MMS-CONTROL-RPY 

MMS-STATUS 

MMS-STATUS-RPY 

4 bits 

Distinguishes MMS 
actions 

Reply 
request 

No reply requested 
From MMS entity 
From End entity 
From MMS and End 
entity 

2 bits 

Is a reply 
requested for the 
action 

MMS 

sequence 

number 

Value 0-127 with 

extension 

0 - 16384 

7 - 14 
bits 

A sequence 
number to 
distinguish MMS 
messages 
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Network 

Number type: 


The address of the 

address 

As in ETS300 175-5 


recipient or 

Address 

7.1.1. 


senderThe type of 

Type: 

Alphanumeric (with 


address used in 


DECT alphabets) 


address fields. 


Numbering plan: 


Values coded as 


As in ETS 300 175-5 


in DECT < < Called 


-7-7-7 


party number> > 


IP address 


IE with some 





IP server name (URI) 


additions 





X.400 address 




LAN address 




wo 97/10684 


31 


PCT/GB96/02243 


Service 

Not specified 

7 bits 

The interworking 

type 

Any method 


service 


Address based IWU 


This is the service 


selection 


type used through 


A message handling 


the message 


facility 


control entity 


Physical 


(secondary IWU 


Voice telephone 


selection in most 


Telex 


of the cases). 


Teletex 




Facsimile group 3 




Facsimile group 4 




Videotex (T.100/T.101 ) 




ERMES 




National paging 




UCI (ETS 300 133-3) 




GSM SMS 




DECT MMS 




DECT LRMS 




IA5 terminal 




X.400 message 




handling 




FTP 




HTTP 




Gopher 




News 




News/NNTP 




Telnet 




Wide area info server 




Host specific file names 




Prospero 
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Service 

None 

4 bits 

These values are 

subtype 

Standard 


related to the 


Telex: 


Service type field 


Standard 


I.e. not ail iisiea 


Via teletex conversion 


\/oliiac oro nr^cciWIo 
ValUt^o aic pLIoolUlc 




Teletex: 


with all service type 






options. The service 


Standard 





options related to 


Oner doc. 




the value of the 


tVi\JI II L ViLIO 


Service type is 





Ctrl doc. 


defined. (TFT; 


TFT ot Doc. tr. Moae 


Telematic File 


TFT of Binary File Tr. 


Transfer). 


TFT of Edifact 




m PSrUN 




in CSPuN 




in analog PSTN 




m digital ISDN 




Facsimile group 3: 




otanoara 




1 r 1 OT basic ir.ivioae 




1 r 1 OT uoc. ir. iviooe 




TFT Of Binary riie. i r. 




1 r 1 OT cOITaCI 




racsimiie group *f. 




otanoara 




Oper. doc. 




IVIOniL QUU 




Ctrl doc. 




TFT of Doc. tr. Mode 




TFT of Binary File Tr. 




TFT of Edifact 
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Message 

Unspecified 

3 bits 

This field indicates 

transmissi 

EncaDSulated 


the structure of the 

on type 

ivi ui I 


MMS message, i.e. 


Body in U-plane 


illljill^iall flicailo 


rieaoer in i^-piane 


sementation and 


Normal 


body in U-plane 




means F profile 




functionality. 
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Message 

Undefined 

7 bits 

This field specifies 

content type 

Specified by the 


the content of the 


service type 


message i.e. the 


Local type 


format of the 


Simple formattable 


message content. 


document 




Basic text: 




lA 5 text (T.50) 




Telex 




Teletex (T.61) 




Videotex 




(T.100/T.101) 




Image 




TIFF image 




GIF image 




JPEG image 




Fax G 4 class 1 




Fax G 3 (T.4/T.30) 




Audio 




AVI audio 




Multipart: mixed 




Multipart: parallel 




Multipart: alternative 




Multipart: digest 




Encapsulated: RFC 




822 or MIME 




Encapsulated: GSM 




SMS 




Encapsulated: X.400 




Octet stream 




application 




Postscript application 




MPEG video 
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Character 

Others 

3 bits 

The data type in 

type coding 

Standard 8 bit 


the user data field 


characters 


Coded as in 


Standard 4 bit coding 


< < Alphanunneric 


Standard 7 bit 


> > IE in DECT 


characters 


with some 


Binary 


additions 


Compressed 




Encrypted 
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Character 

8 bit characters: 

3 bits 

When language 

set coding 

DECT standard 8 bit 


coding is used the 


8 bit ASCII 


lengtn ot ine Tieiu 


US-ASCII 


lo CALCllUCU Willi / 


ISO 8859 




8 bit EBCDIC 




7 bit characters: 




7 bit ERMES 




7 bit standard ASCII 




7 bit ASCII (IA5/T.50) 




Others: 




ASN.1. BER.I 




User specific 




National variations of 




IRA 




Compressed: 




ZIP 




y.^-z Dis 




Encrypted: 




GSM encryption 




DECT encryption 
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Language 

German 

7 bits 

The language of 

coding 

English 


the message 


Italian 




French 




Snani^h 




Dutch 




Swpdl^h 

%.J V V w \J 1 0 1 1 




Danish 




Pnrtunije^p 




Finni*;h 

■^11 II IIOI 1 




Norweaian 




Greek 




Turkish 




Reserved for 




European languages 




Language unspecified 



Time Stamp 

Date, Time, Timezone 

7 

When message 



octets 

was sent 

User data 

Tells the amount of 

1-4 

The length of user 

length 

octets in the user 

octets 

data field 


data field. 



User data 


Variable 

The user data 




defined by 




message content 




and data coding 




type fields 
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Action 

General values: 

7 bits 

Result of the 

result 

Successful 


action 


Unsuccessful 




Command successful 




Command unsuccessful 




Successful 




transactions: 




Message sent to end 




entity 




Message received by 




server 




Message received by 




end entity 




Message replaced by 




the server 




Temporary Error: 




No memory available 




Congestion 




End entity busy 




No response from end 




entity 




Quality of service not 




available 




Error in end entity 




Permanent Error: 




Invalid address 




Incompatible file type 




Invalid network(End 




User not accessible) 




Service rejected 




End entity not available 




Primary IWU 




conversion failed 
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\^\jt III! lai lu 

vaiuc^o oo 111 iviivi^ 

7 or 

1 lie v^Li 1 1 11 1 lai lU 



14 

UUJCwL IIUillUci 


u reservea lor 


/rWIIV^^ com lon^o 

\IVIIV10 OC(^UCllOC 


connection control 


1 lUl 1 ILJCi / 




IT inis Tieio IS 




omitted or it 




contains value 0 




the command is 




related to the 




connection 

Command 

Message related: 

7 bits 

The operation 

type 

Delete 




Replace 




Cancel 




Memory available 




Status Enquiry 




Cancel status enquiry 




Connection related: 




Login 




Logout 



Information 

Status report 

7 bits 


type 

Message/file waiting in 




server 



Escape 

yes 

1 bit 

Indicates the 

commands 

no 


presence of an 

present 



application specific 




command in user 




field 

Control 


Variab 

Indicates if escape 

data length 


le 

data is present 
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Control 
data 


Variab 
le 

Escape field for 
application specific 
commands 

Segmented 
info 


4 

octets 

Contains 

segmentation 

information 


The following actions use the DECT Call Control functionality directly for the 
MMS call controlling. The following clauses are describe generally their 
functionality. The procedures referred here are defined above. The actions are 
described here for consistency but basically they are DECT CC functionality and 
the their true functionality is described below. 

The following actions can be accessed through the MMS-API in the full- and 
half -API cases or similar functionality can be reached through the DECT MNCC- 
SAP in the non-API case. The required information content of these C-MMS 
service actions is defined here and the mapping between respective DECT and 
MMS functions set out below. 

The purpose of the MMS-SETUP action is to initiate a MMS connection through 
the air interface. It contains the procedures 1, 2, and 3. As a result of 
receiving these procedures the fixed MMS entity may also proceed with 
procedure 4. This functionality is done by using DECT CC-SETUP functionality. 

The result of the MMS-SETUP action is accepted by sending a MMS-CONNECT 
message. The receiving MMS entity accepts the MMS call establishment and 
informs the intitating entity. The action is conducted by using DECT CC- 
CONNECT messages. 

In unsuccessful cases of the connection establishment the release of the 
connection is a matter of the lower layer entities. The connection release is 
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done in unsuccessful cases either by MMS-RELEASE of by MMS-RELEASE-COM 
(see figure 21 ). 

The following table shows the MMS-SETUP message contents 


Field in MMS- 
SETUP 

Status 

Comment 

Iwu-attributes 

M 

Defines the profile requirements 
(the interworking unit) 

Cailed-Party- 
Number 

0 

Defines the server number. This 
number is optional. 

Caliing-Party- 
Number 

O 

Informs the server number. This 
number is optional. 


The MMS-CONNECT message contains no MMS specific information. 

A normal release between MMS is done by the MMS-RELEASE action 
procedure. This action contains the procedure 1 1 of figure 14. It may also 
contain procedure 10. The response is MMS-RELEASE-COM. 


Abnormal situations are done by MMS-RELEASE-COM message. 

The detailed functionality of these procedures are in the layers below MMS (see 
figure 22). 

The following table shows the MMS-RELEASE message contents 


Field in MMS- 

Status 

Comment 

RELEASE 
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Release reason 

0 

Defines the reason for the 



release 


The following table shows the MMS-RELEASE-COM nnessage contents 


Field in MMS- 
RELEASE-COM 

Status 

Comnnent 

Release reason 

O 

Defines the reason for the 
release 


The information element coding in C-MMS actions is done as defined below. 

The defined MMS protocol information elements could be implemented to the 
DECT layers as illustrated in figure 23. A group of new information elements 
have to be defined but also a group of already existing DECT elements could be 
utilized by adding some new codings. Additions of the old and new information 
elements into DECT Call Control or COMS and U-piane messages has to be 
done. 

Also the primitives related to the MMS-API should be defined. In the case MMS- 
API is used the layer does mapping between MMS-API primitives and DECT 
NWK and U-plane primitives. 

The mapping of the M-MMS and C-MMS information elements into DECT 
messages will now be defined. The reference column of the tables refer to the 
clause which defines the information element. By reading the IE the field 
mapping is straigthforward. Detailed information on how the used DECT 
messages are coded is also presented. 

The following table shows the M-MMS messages 
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Item 
No 

MMS MSG 

DECT MSG 

Status 
in GAP 

Ref. 

Map 
Status 

Note 

1 

MMS-SEND 

CC-INFO 

M 

7.3.2.1 

M 


2 

MMS-SEND 

CC-INFO/U- 
plane LAPU 
frame 

1 

7,3.2.2 

M 

1. 

3 

MMS-SEND-RPY 

CC-INFO 

M 

7.3.2.3 

M 


4 

MMS-RETRIEVE 

CC-INFO 

M 

7.3.2.4 

M 


6 

MMS-RETRIEVE- 
RPY 

CC-INFO 

M 

7.3.2.5 

M 


5 

MMS-RETRIEVE- 
RPY 

CC-INFO/U- 
plane LAPU 
frame 

t 

7.3.2.6 

M 

1. 

7 

MMS- 
COMMAND 

CC-INFO 

M 

7.3.2.7 

M 


8 

MMS- 

COMMAND-RPY 

CC-INFO 

M 

7.3.2.8 

M 


9 

MMS-STATUS 

CC-INFO 

M 

7.3.2.9 

M 


10 

MMS-STATUS- 
RPY 

CC-INFO 

M 

7.3.2.10 

M 



NOTE. This mapping take place only when the MMS (F-data profile) is 
using the MMS. 


The following table shows the MMS-SEND - CC-INFO 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOT 
E 


MMS-SEND 

CC-INFO 
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1 

Action type 

Facility or MMS 


8.2.4; 8.2.6 

M 

2. 

2 

Reply request 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

3 

Recipient 
address 

Called party 
number 


8.2.5 

M 


4 

Sender address 

Calling party 
number 


8.2.5 

M 


5 

Service type 

Facility or MMS 


8.2.4; 8.2.6 

M 

2. 

6 

Service subtype 

Facility or MMS 


8.2.4; 8.2.6 

M 

2. 

7 

Message 

transmission 

type 

Facility or MMS 


8.2.4; 8.2.6 

M 

2. 

8 

Data content 
type 

Facility or MMS 

, 

8.2.4; 8.2.6 

M 

2. 

9 

Time Stamp 

Time/data 

I 

8.2.7 

M 

3. 

10 

MMS sequence 
number 

Facility or MMS 


8.2.4; 8.2.6 

M 

2. 

11 

Character type 
coding 

Alphanumeric 


8.2.8 

M 

1. 

12 

Character set 
coding 

Alphanumeric 


8.2.8 

M 

1. 

13 

Language coding 

Alphanumeric 


8.2.8 

O 

1. 

14 

User data length 

Alphanumeric 


8.2.8 

M 

1. 

15 

User data 

Alphanumeric 


8.2.8 

M 

1. 

16. 

Segmented info 

Segmented info 


ETS 300 

175-5, 

7.7.37 

M 

1. 
5. 

18. 

Content type 

IWU-TO-IWU 


8.2.12 


4. 

19. 

User data 

IWU-TO-IWU 


8.2.12 


4. 


wo 97/10684 


45 


PCT/GB96/02243 


NOTE 1. This mapping take place only when the LRMS (E-data profile) is 
using the MMS. 

NOTE 2. Either a new coding of Facility element is used or a new 
information element MMS is defined and used (See below). 

NOTE 3. A new information element is defined for this purpose below. 

NOTE 4. This mapping takes place if the < Message transmission type> 
field of the MMS message contains value "Encapsulated". 

NOTE 5. This mapping takes place if the < Message transmission type> 
field of the MMS message contains value "Multipart" or the 
segmentation may function independently of the MMS 
messaging as DECT NWK internal matter. 


The following table shows the MMS-SEND - CC-INFO/U-plane LAPU frame 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-SEND 

CC-INFO 





1 

Action type 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

2 

Reply request 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

3 

Recipient 
address 

Called party 
number 

1 

8.2.5 

M 


4 

Sender address 

Calling party 
number 

1 

8.2.5 

M 


5 

Service type 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 
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6 

Service subtype 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

7 

Message 

transmission 

type 

Facility or MMS 


8.2.4; 
8.2.6 

M 

2. 

8 

Data content 

Facility or MMS 

1 

8.2.4; 

M 

2. 


type 

LAPU frame 


8.2.6 


4. 

9 

Time Stamp 

Time/data 

1 

8.2.7 

M 

3. 

10 

MMS sequence 

Facility or MMS 

1 

8.2.4; 

M 

2. 


number 

LAPU frame 


8.2.6 


4. 

1 1 

Character type 
coding 

LAPU frame 

1 

7.3.4. 

M 

1. 

12 

Character set 
coding 

LAPU frame 

1 

7.3.4. 

M 

1. 

13 

Language coding 

LAPU frame 

1 

7.3.4. 

0 

1. 

14 

User data length 

LAPU frame 

1 

7.3.4. 

M 

1. 

15 

User data 

LAPU frame 

1 

7.3.4. 

M 

1. 


NOTE 1 . This mapping take place only when the MMS (F-data profile) is 
using the MMS. Then the < Message transmission type> field of 
the MMS message contains value "Body in U-plane" 

NOTE 2. Either a new coding of Facility element is used or a new 
information element MMS is defined and used. (See below). 

NOTE 3. A new information element is defined for this purpose in below. 

NOTE 4. The element is carried in both LAPU frame and CC-INFO 
message. 


The following table shows the MMS-SEND-RPY - CC-INFO 
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Item 

Message coding 

Message coding 

GAP 

Ref. 

Map 

NOTE 

No 

MMS 

DECT NWK 

status 


status 



MMS-SEND-RPY 

CC-INFO 





1 

Action type 

Facility or MMS 

I 

8.2.4; 8.2.6 

M 

2. 

2 

MMS sequence 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 


number 






3 

Action result 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 


NOTE 2. Either a new coding of Facility element is used or a new 
information element MMS is defined and used. (See chapter 8). 


The following table shows the MMS-RETRIEVE - CC-INFO 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-RETRIEVE 

CC-INFO 





1 

8.2.4; 8.2.6 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

2 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

3 

Service type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

4 

Intermediate 
server address 

Called party 
number 

1 

8.2.5 

M 


5 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

6 

Data object type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

7 

Command type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 


The following table shows the MMS-RETRIEVE-RPY - CC-INFO 
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Item 
No 

Message coding 
MMS 

Message 
coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-RETRIEVE- 
RPY 

CC-INFO 





1 

Action type 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

2 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

3 

Service type 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

4 

Networi< 
address (with 
address type) 

Called party 
number 

1 

8.2.4; 
8.2.6 

M 


5 

Data content 
type 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

6 

Action result 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

7 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 
8.2.6 

M 

2. 

8 

Time Stamp 

Tirne/Date 

1 

8.2.7 

M 

3. 

9 

Character type 
coding 

Alphanumeric 

1 

8.2.8 



10 

Character set 
coding 

Alphanumeric 

1 

8.2.8. 

M 

1. 

11 

Language 
coding 

Alphanumeric 

1 

8.2.8. 



12 

User data length 

Alphanumeric 

1 

8.2.8. 

M 

1. 

13 

User data 

Alphanumeric 

1 

8.2.8. 

M 

1. 
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16. 


Segmented info 


Segmented info 


1 
1 

cTS 

M 



300 


5. 


175- 




5. 




7.7.3 




7. 




NOTE 1. This mapping take place only when the LRMS (E-data profile) is 
using the MMS. 

NOTE 2. Either a new coding of Facility element is used or a new 
information element MMS is defined and used. (See below). 

NOTE 5. This mapping takes place if the < Message transmission type> 
field of thei MMS message contains value "Multipart" or the 
segmentation may function independently of the MMS 
messaging as DECT NWK internal matter. 


The following table shows the MMS-RETRIEVE-RPY - CC-INFO/LAPU frame 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-RETRIEVE- 
RPY 

CC-INFO 





1 

Action type 

Facility or MMS 

1 

8.2.4; 8,2.6 

M 

2. 

2 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

3 

Service type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

4 

Network 
address (with 
address type) 

Called party 
number 

1 

8.2.5 

M 



wo 97/10684 


50 


PCT/GB96/02243 


5 

Data content 
type 

Facility or MMS 
LAPU frame 

1 

8.2.4; 8.2.6 

M 

2. 
4. 

6 

Action result 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

7 

MMS sequence 
number 

Facility or MMS 
LAPU frame 

1 

8.2.4; 8.2.6 

M 

2. 
4. 

8 

Time Stamp 

Time/Date 

1 

8.2.7 

M 

3. 

9 

Character type 
coding 

LAPU frame 


7.3.4 



10 

Character set 
coding 

LAPU frame 


7.3.4 

M 

1. 

11 

Language 
coding 

LAPU frame 


7.3.4 



12 

User data length 

LAPU frame 


7.3.4 

M 

1. 

13 

User data 

LAPU frame 


7.3.4 

M 

1. 


NOTE 1. This mapping take place only when the MMS {F-data profile) is using 
the MMS. 

NOTE 2. Either a new coding of Facility element is used or a new information 
element MMS is defined and used. (See below). 

NOTE 3. A new information element is defined for this purpose below. 


NOTE 4. The element is carried in both LAPU frame and CC-INFO message. 


The following table shows the MMS-COMMAND - CC-INFO 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS- 
COMMAND 

CC-INFO 
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1 

Action type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

2 

Reply request 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

3 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

4 

Service type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

5 

Time Stamp 

Time/Date 

1 

8.2.7 

M 


6 

Intermediate 
server address 

Called party 
number 

1 

8.2.5 

M 


7 

Data content 
type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

8 

Command 
object 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

9 

Command type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

10 

Escape 

commands 

present 

Facility or MMS 


8.2.4; 8.2.6 

M 

2. 

11 

Control data 
length 

IWU-TO-IWU 

! 

8.2.12 

M 


12 

Control data 

IWU-TO-IWU 

1 

8.2.12 

M 



NOTE 2. Either a new coding of Facility element is used or a new 
information element MMS is defined and used. (See below). 


The following table shows the MMS-COMMAND-RPY - CC-INFO 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS- 
COMMAND-RPY 

CC-INFO 





1 

Action type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 
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9 


2 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

3 

Time Stamp 

Time/Date 

1 

8.2.7 

M 


4 

Command 
object 

Facility or MMS 

1 

8.2,4; 8.2.6 

M 

2. 

5 

Command type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

6 

Action result 

Facility or MMS 

1 

8.2.4; 0.2.D 

M 

Z, 

9 

Control data 
length 

IWU-TO-IWU 

1 

8.2.12 

M 


10 

Control data 

IWU-TO-IWU 

1 

8.2.12 

M 



NOTE 2. Either a new coding of Facility element is used or a new 
information element MMS is defined and used. {See below). 


The following table shows the MMS-STATUS - CC-INFO 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-STATUS 

CC-INFO 





1 

Action type 

Facility or MMS 

I 

8.2.4; 8.2.6 

M 

2. 

2 

Reply request 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

3 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

5 

Time Stamp 

Time/Date 

1 

8.2.7 

M 


6 

Information type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

7 

Action result 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

8 

Command 
object 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 
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9 

Control data 
length 

IWU-TO-IWU 


8.2.12 

M 


10 

Control data 

tWU-TO-IWU 


8.2.12 

M 


11 

Sender address 

Calling party 
number 

1 

8.2.5 

M 


12 

Service type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

13 

Service subtype 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

14 

Data content 
type 

Facility or MMS 


8.2.4; 8.2.6 

M 

2. 

15 

Time Stamp 

Time/Date 

1 

8.2.7 

M 


16 

User data length 

Facility or MMS 

I 

8.2.4; 8.2.6 

M 

2. 


NOTE 2. Either a new coding of Facility elennent is used or a new 
information element MMS is defined and used. (See below). 


The following table shows the MMS-STATUS-RPY - CC-INFO 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-STATUS- 
RPY 

CC-INFO 





1 

Action type 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

2 

MMS sequence 
number 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 

3 

Action result 

Facility or MMS 

1 

8.2.4; 8.2.6 

M 

2. 


NOTE 2. Either a new coding of Facility element is used or a new 
information element MMS is defined and used. (See below). 
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The following table shows the C-MMS messages 
Table x: List of mapped C-MMS messages 


item 
No 

MMS MSG 

DECT MSG 

Status 
in GAP 

Ref. 

Map 
Status 

1 

MMS-SETUP 

CC-SETUP 

M 

7.3.3.1 

M 

2 

MMS-CONNECT 

CC-CONNECT 

M 

7.3.3.3 

M 

3 

MMS-RELEASE 

CC-RELEASE 

M 

7.3.3.2 

M 

4 

MMS-RELEASE- 
COM 

CC-RELEASE-COM 

M 

7.3.3.2 

M 


The following table shows the IVIMS-SETUP - CC-SETUP 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-SETUP 

CC-SETUP 





1 

Iwu-attributes 

Iwu-attributes 

1 

8.2.2 

M 


2 

called party 
number 

called party 
number 

1 


M 


3 

calling party 
number 

calling party 
number 

1 


M 



The following table shows the MMS-CONNECT - CC-CONNECT 


Item 

Message coding 

Message coding 

GAP 

Ref. 

Map status 

NOTE 

No 

MMS 

DECT NWK 

status 
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MMS-CONNECT 

CC-CONNECT 






The following table shows the MMS-RELEASE - CC-RELEASE 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-RELEASE 

CC-RELEASE 






Release reason 

Release reason 






The following table shows the MMS-RELEASE-COM - CC-RELEASE-COM 


Item 
No 

Message coding 
MMS 

Message coding 
DECT NWK 

GAP 
status 

Ref. 

Map 
status 

NOTE 


MMS-RELEASE- 
COM 

CC-RELEASE- 
COM 






Release reason 

Release reason 






The added information element required in addition to GAP will now be defined. 
As defined elsewhere in this document the MMS virtual protocol can be 
regarded as service that supports the DECT data teleservices such as short 
messaging and facsimile. Thus , the idea here is to provide the MMS User 
control coding and MMS messaging coding in the way DECT supplementary 
services are provided. This means that the MMS can be intitated during the call 
establishment but also a low bearer service connection can be upgraded into a 
full MMS connection. It should be noted that in the case of E-profile (LRMS) the 
MMS cannot be a supplementary service for voice call since the voice call has 
its own transaction identifier and the MMS service is cannot provide any 
additional information to this service. This is why in this document the 
expression Supplementary Service is avoided when referred to MMS. Thus 
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MMS is an additional service that can be used to upgrade a bearer service into 
a full teleservice and this can be done even during the bearer service 
connection. This is possible in the case of F-data profile in a way that the C.2 
profile which is the bearer service under the F can be upgraded into F profile by 
initiating the MMS connection during the call. In the case of LRMS a completely 
new CC instance has to be intitated without U-plane. The E profile can be also 
upgraded into F profile by adding a C.2 U-plane connection under the MMS 
protocol. Thus the following rules apply (see figure 24). 

• If C.2 is on and the MMS is activated to the same Call Control transaction 
the connection is upgraded into F.2 profile. Also other way around. 

• If E.2 is on and the C.2 U-plane is activated to the same Call Control 
transaction the connection is upgraded to F.2 connection. Also other way 
around. 

• The C.2 and E.2 can exist at the same time in a same terminal with separate 
transactions as well as F.2 and E.2. 

For upgrading the C.2 to F.2 profile uses the << Feature activate >> 
element. This can be done only in the direction PP to FP, The FP can 
indicate MMS activation with < < Feature indicate > > field. 

• For upgrading the E.2 to F.2 profile the CC-SERVICE-CHANGE message has 
to be used. 

<<Facilty>> or new <<MMS protocol >> element in {CC-INFO} 
message is used for MMS message transfer in general, 

• When E and F profile call is established the systems initiate the MMS by 
default. 
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Since prior art DECT air interfaces support only a limited service negotiation 
capability, also a new service negotiation is also now proposed by adding the 
< <iwu-attributes > > element to the {CC-INFO} message. In this way the 
service negotiation is more flexible and some interworking unit/network service 
parameters can be negotiatied/changes even during the call establishment. Also 
a new coding of the < <iwu-attributes> > element is defined below to provide 
more general coding to IWU service selection. This was done due to fact that 
current coding of the < <iwu-attributes> > element is only ISDN oriented and 
does not fit well into general data service selection. The new coding is 
backwards compatible with the old coding. 

The call establishment has been illustrated in figure 24 in actions 1 and 2. It 
should be noted that additional signalling may take place between the {CC- 
SETUP} and {CC-CONNECT}. The {CC-SETUP} message will contain the 
following information in addition to the GAP requirements. 


Information 
element 

status 
in 

GAP 

Field within the 

information 

element 

Standard 
values within 
the field/IE 

Normative 
action/comment 

< < Portable 
identity > > 

M 



Coded as in GAP 

< < Fixed 
Identity > > 

M 



Coded as in GAP 

< < Basic 
service > > 

M 






<Call class> 

1110 

"Messaging call setup" 
Note 1 . 



< Basic 
service > 

1111 

"Other" The coding is 
defined by < <iwu 
attributes > > and 
< <call attributes > > 


wo 97/10684 


58 


PCT/GB96/02243 


< < Iwu- 
attributes> > 

1 



Note 1. 



< Coding 
sianuara 

0 1 

"Profile specific coding" 
iMoie 1 . 



< Profile ID> 

0 0 0 1 1 

0 0 1 0 O 

" E profile " or 
r profile Note 1 . 



<HLC ID> 

1 0 

Octet identifier Note 1 . 



<HLC coding 
indicator > 

0 0 0 0 1 

"User protocol ID 
present" Note 1 , 



<User protocol 
ID> 

110 0 1 

"DECT LRMS/MMS 
(MMSP)" Note 1. 





Rest of the codings are 
depending on the 
requested service. Note 
1. 

< <call 
attributes > > 

1 






< Coding 
standard > 

0 0 

DECT 



Network layer 
attributes 

0 110 0 
0 1 10 1 

"DECT LRMS service 
profile (E data profile" or 
"DECT MMS service 
profile (F data profile)" 
Note 1. 





Rest of the codings are 
depending on the 
requested service. Note 
1. 
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< <connectio 
n 

attriubtes> > 

1 








All codings are situation 
and profile dependent 



< < Number of 
bearer 
coding > > 

0 0 0 0 0 

"No-U-plane" in E profile 
case 

< <Called 
party 

nunnber> > 

I 






< Number 
type> 

0 1 1 

"Server number" Note 1 . 



< Numbering 
plan 

identification > 


Value depends on the 
interworked network 

< <CalIing 
party 

nunnber> > 

1 






< Number 
type> 

0 1 1 

"Network specific 
number" 



< Numbering 
plan 

identification > 


Value depends on the 
interworked network 


NOTE. Contains new coding(s). See below. 


{CC-CONNECT} message content is as it is defined in the GAP DRAFT prETS 
300 444. Version 2.02. Radio Equipment and Systems IRES); Digital European 
Cordless Telecommunications (DECT): Generic Access Profile (GAP). European 
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Telecommunications Standards Institute. May 1994.138 pages, i.e. all fields are 
optional. 

The Low Rate Messaging Service ILRMS, the E-data profile) messaging uses 
{CC-INFO} messages to convey the MMS messages. In this case the CC-INFO 
contains the MMS user data information, the MMS user data control 
information as well as the MMS messaging information. 


The following table shows the {CC-INFO} message content for this: 


Information 
element 

Status 
in GAP 

rieid within tne 

information 

element 

Standard 
values 
within the 
field/IE 

iMormaiive 
action/comment 

<<Multi 
keypad > > 

M 



Not used with 
MMS 

< < Facility > > 

1 



Either this element 
or < <MMS> > 
element 



< Service 
discriminator> 

10 0 10 

"Discriminator for 
MMS service 
applications'* 



< Components 
> 


Contains the MMS 
control information 

< <Calling- 
Party- 

Number> > 

1 



Defines the MMS 
message sender 
number. Note 1 . 



< Number 
type> 

0 1 1 

"Network specific 
number" 
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< Numbering 
plan 

identification > 


Value depends on 
the interworKed 
network 

< <Called- 
Party- 

Nunnber> > 

1 



Defines the MMS 
message recipient 
number 



<Number 
type> 

0 1 1 

"Network specific 
number" 



<Nunnbering 
plan 

identification > 


Value depends on 
the interworked 
network 

< <Called- 
Party- 

Subaddress > > 

1 



May contain 
additional 
information related 
to the recipient 



< Subaddress 
type> 


Value depends on 
the interworked 
network 



< Odd/Even > 


Value depends on 
the interworked 
network 

< < Time/date > 
> 

1 


• 

Date information. 
Note 1 . 

< <MMS> > 

1 



Either this of 
< < Facility > > 
element contains 
the MMS control 
information. Note 
1. 
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< < Segmented 
info> > 

1 



Contains 
information if the 
< < Alphanumeric 
> > element has 
been segmented. 
Note 1. 

< < Alphanumer 
ic> > 

1 



Note 1. 



< Character 
type> 





< Odd/Even > 





< Character set 
coding > 





<List of 
characters > 


Contains the 

message 

information 

< <IWU-TO- 
IWU> > 

1 



May contain upper 
layer messages or 
escape commands 



< Protocol ID> 


Contains coding 
regarding the 
message content 


NOTE 1. New coding(s)/element. See below. 

The Multimedia Messaging Service (MMS, the F-data profile) messaging uses 
CC-INFO messages to convey the MMS messages. In this case the CC-INFO 
contains the MMS user data control information as well as the MMS messaging 
information. The user data information is conveyed through the U-plane LAPU 
connection. The MMS message in CC-INFO transmits the control information 
related to the connection. 
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The following table shows the {CC-INFO} message content for this: 


Information 
element 

status 
in 

GAP 

Field within the 

information 

element 

Standard 
values 
within the 
field/IE 

Normative 
action/comment 

< <Multi 
keypad > > 

M 



Not used with MMS 

< < Facility > > 

1 



Either this element or 
< <MMS> > 
element. Note 1. 



< Service 
discriminator > 

10 0 10 

"Discriminator for 
MMS service 
applications" 



< Components 
> 


Contains the MMS 
control information 

< <Calling- 
Party- 

Number> > 

1 



Defines the MMS 
message sender 
number. Note 1. 



< Number 
type> 

0 1 1 

"Network specific 
number" 



<Numbering 
plan 

identification > 


Value depends on the 
interworked network 

< <Called- 
Party- 

Number> > 

1 



Defines the MMS 
message recipient 
number 



< Number 
type> 

0 1 1 

"Network specific 
number" 
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< Numbering 
plan 

identification > 


Value depends on the 
interworked network 

< <Called- 
Party- 

Subaddress> > 

1 



May contain 
additional information 
related to the 
recipient 



<Subaddress 
type> 


Value depends on the 
interworked network 



< Odd/Even > 


Value depends on the 
interworked network 

< < Time/date > 
> 

1 



Date information. 
Note 1 . 

< <MMS> > 

1 



Either this of 
< < Facility > > 
element contains the 
MMS control 
information. Note 1 . 


NOTE 1. New coding(s)/element. See below: 

The following frame is carried in the LAPU information field. The content is the 
same as in < < Alphanumerio > element. 


Information 

Field within 

Length 

Normative action/comment 

element 

the 




information 




element 
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< <MMS 
sequence 
coding > > 


1-2 octets 
(7 bits used 
of each 
octet) 

This field has the same 
value as in the CC-INFO 
message carried at the 
same time. 

< < Data 
content 
type > > 


1 octet ( 7 
bits used of 
each octet) 

This field has the same 
value as in the CC-INFO 
message carried at the 
same time. 

< Length of 
contents > 


1-4 octets ( 
7 bits used 
of each 
octet) 

This element is coded as 
the User data length 

< Character 
type > 



Coded as respective field in 
8.2.8 

< < Alphanumerio > 
element. 

< Odd/Even > 



Coded as respective field in 
8,2.8 

< < Alphanumeric > > 
element. 

< Character set 
coding > 



Coded as respective field in 
8.2.8 

< < Alphanumerio > 
element. 

<Data> 



Contains the message 
information 


Note that the first three elements are coded exactly like respective codings in 
CC-INFO (the bit 8 of each octet is used for element coding purposes). 
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There are three different cases: the call service change, call suspension, call 
resumption and service up/downgrading 

The call suspension illustrated in action 5 in figures 25 and 26 and is done as 
described in the C.2 data profile Draft prETR 300 xxx. Version 5.00. Work Item 
No:DE/RES-03-030. Radio Equipment and Systems (RES); Digital European 
Cordless Telecommunications. Data Services Profile. Profile. Generic data link 
service. Service Type C, Class 2. European Telecommunications Standards 
lnstitute.20.1 .1995. 260 pages and is optional. 

The call resumption illustrated in action 5 in figures 25 and 26 and is done as 
described in the C.2 data profile and is optional. 

The action 5 in the figures 25 and 26 can be the link up/down grading 
procedure. This message is used only when the E profile connection is 
upgraded to F.2 profile connection by initiating C.2 profile U-plane. 


The following table shows the {CC-SERVICE-CHANGE} message content: 


information 
element 

Field within 
the 

information 
element 

Standard 
values 
within the 
field/IE 

Normative action/comment 

< < Service- 
change-info > 



Contains the service change 
info 


< Change 
mode 
coding > 

0 0 10 

Bandwidth change 

< < Connection 
attributes > > 



Contains the new 
connection attributes 
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< Symmetry > 


Connection related values. 
See 7.7.11 in ETS 300 175- 
5 


< Connection 
identity 
coding > 

1 N N N 

Advanced connection 
number. The current 
connection number. 


< Bearer 
definition 
coding > 


Connection related values. 
See 7.7.11 in ETS 300 175- 
5 


< Number of 

bearer 

coding> 

0 0 0 0 0 

"No U-plane". This value is 
used when F profile is 
downgraded to E. 



n n n n n 

Number of bearers. This 
field contains the requested 
bearer value when 
upgrading the E to F profile 
connection. 


The procedure of up/downgrading between F - and C-data profiles is used for 
changing a bearer services (C-data profile) to a teleservice (F-data profile). A PP 
can initiate this type of procedure by sending a << feature activate >> 
information element in the {CC-INFO} message. The << feature activate >> 
element contains value "MMS service" in the < < Feature coding > > field. The 
Fixed part responses with {CC-INFO} message containing << Feature 
indicate >> element with value "MMS Service" in the << Feature coding >> 
field and "Activated" in the << Status indicator >> to indicate successful 
MMS activation. 

The following table shows the {CC-INFO} message content: 
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Information 
element 

status 
in 

GAP 

Field within 
the 

information 
element 

Standard 
values 
within the 
field/IE 

Normative 
action/comment 

< < Feature 
activate > > 

1 



In PP to FP direction 



< Feature 
coding > 

X X X X 

"MMS activate". Note 1. 

< < Feature 
indicate > > 

1 



In FP to PP direction 



< Feature 
coding > 

X X X X 

MMS indicate. Note 1. 


NOTE 1. New coding{s)/element. See below. 

The procedure of connection parameter negotiation is used to negotation IWU 
service related parameters or affect the IWU selection during the established 
connection or during the connection establishment. The procedure takes place 
by sending new reqested values in < <iwu-attributes> > element of the {CC- 
INFO} message. This procedure can be used also with other data profiles i.e. no 
MMS functionality is needed. The {CC-INFO} message with new values can be 
sent an message of its own (requesting IWU/parameter change), as a response 
to {CC-SETUP} message (reflecting new parameters for a connection i.e. 
service negotiation) or as a response a {CC-INFO} requesting IWU 
service/parameter change. An example of the usage of this functionalty in the 
case of GSM interworking is given below. 
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The following table shows the {CC-INFO} message content: 


Information 
element 

status 
in 

GAP 

Field within the 

information 

element 

Standard 
values within 
the field/IE 

Normative 
action/comment 

< < Iwu- 
attributes > > 

1 



Note 1 , 



< Negotiation > 

1 1 0 

"Connection 
parameter 
negotiation". Note 
1. 





Other codings are 
done according to 
the requested 
service. 


NOTE 1. New coding{s)/element. See below. 


The call release procedures are done as defined in the GAP profile. 

The following M-MMS-SAP primitives are used in the MMS-API interface of the 
full-API model. 


Primitive 

Req 

Cfm 

Ind 

Res 

M-MMS-SEND- 

X 

X 

X 

X 

M-MMS-RETRIEVE- 

X 


X 


M-MMS-CONTROL- 

X 

X 

X 

X 


The M/C-MMS-SAP primitives of the full-API model are the same primitives as 
in C-MMS-SAP of half-API model but they are used directly by the M-MMS part. 
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Primitive 

Req 

Cfm 

Ind 

Res 

M-MMS-SETUP- 

X 


X 


M-MMS-CONNECT- 

X 

X 

X 


M-MMS-RELEASE- 

X 

X 

X 

X 

M-MMS-MODIFY- 

X 

X 

X 



The rules how the M-MMS part uses the M/C-MMS-SAP are defined in each 
service interworking description. 

The following M-MMS-SAP primitives are used in the MMS-API interface of the 
half-API model. 


Primitive 

Req 

Cfm 

Ind 

Res 

M-MMS-SEND- 

X 

X 

X 

X 

M-MMS-RETRIEVE- 

X 


X 


M-MMS-CONTROL- 

X 

X 

X 

X 


The following C-MMS-SAP primitives are used in the MMS-API interface of the 
half-API model. 


Primitive 

Req 

Cfm 

Ind 

Res 

M-MMS-SETUP- 

X 


X 


M-MMS-CONNECT- 

X 

X 

X 


M-MMS-RELEASE- 

X 

X 

X 

X 

M-MMS-MODIFY- 

X 

X 

X 


M-MMS-GRADING- 

X 


X 
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NOTE: M-MMS-GRADING- primitives are used for up/down grading the 
connection between C and F data profiles. 

The non-API interface functionality is defined below. 

The following DECT network layer Call Control primitives provide for MMS 
message transportation. 

IVINCC-INFO{req,ind} 

In addition if the U-plane is used for data transmission the following DECT DLC 
layer U-plane primitive is used. 

DLU-LU3_DATA {req, ind} 

The MMS messages are conveyed by this primitive by containing the MMS 
messages in a parameter. 

For MMS call control the following DECT network layer Call Control primitives 
will be used. 

MNCC-SETUP- {req, ind} 
MNCC-CONIMECT- {req, cfm, ind} 
MNCC-RELEASE- {req, cfm, ind, res} 
MNCC-MODIFY- {req, cfm, ind} 
MNCC-INFO{req, ind} 

The MMS messages are conveyed by this primitive by containing the MMS 
messages in a parameter. 

The mapping in the MMS-API case between M-MMS-SAP and NWK primitives 
in full and half-API models is done as follows: 
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MMS primitive 

MNCC prinnitive 

M-MMS-SEND{req, ind} 

MNCC-INFO{req, ind} 

M-MMS-RETRIEVE{req, ind} 

MNCC-INFO{req, ind} 

M-MMS-CONTROL-{req, 
ind} 

MNCC-INFO{req, ind} 


The following mapping is done for the User data part (parameter) only in the 
case DECT U-plane is used. Other parameters are mapped as indicated before 
i.e. the User control data part is mapped to MNCC-INFO. 


IVIIVIS primitive 

MNCC primitive 

M-MMS-SEND{req, ind} 

DLU-LU3_DATA{req. ind} 


All other primitives are produced inside the MMS virtual layer. 


The mapping of C-MMS primitives in the MMS-API case between C-MMS-SAP 
and NWK primitives is done as follows: 


MMS primitive 

MNCC primitive 

M-MMS-SETUP-{req, ind} 

MNCC-SETUP-{req, ind} 

M-MMS-CONNECT-{req, cfm, ind} 

MNCC-CONNECT-{req, cfm, ind} 

M-MMS-RELEASE- {req, cfm, ind. 
res} 

MNCC-RELEASE- {req, cfm, ind, res} 

M-MMS-MODIFY- {req, cfm, ind} 

MNCC-MODIFY- {req, cfm, ind} 

M-MMS-GRADING- {req, cfm. ind} 

MNCC-INFO{req, ind} 
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The parameters depend on the content of the messages. The parameters and 
their values can be derived from the message contents as described herein. 

The following new codings to the DECT network layer are preferred in order to 
provide MMS connections. 

The purpose of the << BASIC-SERVICE > > element (see Subclause 7.6.4 of 
ETS 300 175-5 2nd edition) is to indicate the basic aspects of the service 
requested. This element allows the user to indicate the use of default 
attributes, thereby reducing the length of the set-up message (see figure 27). 

Call class (octet 2) 

Bits 8 7 6 5 Meanino 

1 0 0 0 Normal call set-up 

10 0 1 Internal call (typically used in residential environments) 
10 10 Emergency call set-up 
10 11 Service call set-up 

110 0 External handover call set-up (see subclause 9.3,1.1) 
110 1 Supplementary service call set-up 

1110 Messaging service call setup 
All other values reserved. 

Basic service (octet 2) 

Bits 4 3 2 1 Meanino 

0 0 0 0 Basic speech default set-up attributes (NOTE and subclause 
9.3.1.1) 

0 10 0 DECT GSM IWP profile (Phase 2) 

1111 Other (see subclause 9.3.1 .1 ) 
All other values reserved. 
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NOTE: The value of this field may be used in future standards to 
indicate "specific profile default setup attributes". 


The purpose of the < < CALL-ATTRIBUTES > > element (see Subclause 7.7.5 in 
ETS 300 175-5 2nd edition) is to describe the higher layer service to be 
provided by the DECT protocol. The element may be repeated in a set-up 
message when using service negotiation (see figure 28), 

Coding standard (octet 3): 
Bits 7 6 Meanino 

0 0 DECT standard coding 

All other values reserved. 


Network layer attributes (octet 3): 

Bits 5 4 3 2 1 Meanino 
0 0 0 0 0 Undefined 
0 0 0 0 1 Basic speech 
0 1 0 0 0 DECT GSM IWP profile phase 2 
0 110 0 DECT LRMS service profile (E data profile) 
0 110 1 DECT MMS service profile (F data profile) 
All other values reserved. 


The following presentation of thie IWU-ATTRIBUTES (see Subclause 7.7.21 in 
ETS 300 175-5 2nd edition) intends to expand the functionality of the element 
to be compatible also with other services than just ISDN connections. However 
the intention was to maintain compatibility with the older version. This 
proposed element contains also information carried in << END-TO-END- 
COMPATIBILITY > > element. The purpose was to combine all information 
relating to the IWU selection to the same element. However, another option is 
to leave the << END-TO-END-COMPATIBILITY > > element as a independent 
element and cut those overlapping part off from this element. 
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ine purpose of the << IWU- ATTRIBUTES > > element is to proviae a means 
for service compatibility information to be exchanged (e.g. between a PP 
application and a FP interworking unit). This element is transferred transparently 
by the DECT protocol entities (see figure 29). Note - the octets 7-16 could be 
left out and replaced by << end-to-end compatibility > > element. In this case 
the references to the < <iwu-attributes> > element in this document means a 
reference to both < <iwu-attributes> > and << end-to-end compatibility >> . 
Also, in this case both these elements should be added to the {CC-INFO} 
message in the case of connection parameter negotiation. 


Coding standard (octet 3): 
Bits 7 6 Meaning 

0 0 DECT standard coding 

O 1 Profile defined coding 

All other values reserved. 
Profile coding (octet 3): 
Bits 5 4 3 2 1 Meaning 

0 0 0 0 0 A/B data profile 

0 0 0 0 1 C data profile 

0 0 0 1 0 D data profile 

0 0 0 1 1 E data profile 

0 0 1 0 0 F data profile 

All other values reserved. 
Negotiation indicator (octet 4): 
Bits 7 6 5 Meaning 

0 0 0 Negotiation not possible 

10 0 Exchanged parameter negotiation 

110 Connection parameter negotiation 
All other values reserved. 
Network identity (octet 5): 
Bits 7 6 Meaning 

0 0 octet identifier 


RECTIFIED SHEET (RULE 91) 
ISA/EP 
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All other values reserved. 

External connection type (octet 5): 

Bits 4 3 2 1 Meaning 

0 0 0 ONot applicable 

0 0 0 1 Connection oriented 

0 0 1 0 Permanent Virtual Circuit 

0 0 11 Non-permanent Virtual Circuit 

0 10 0 Datagram 

1 0 0 0 Connectionless 
All other values reserved. 

Network (octet 5a): 
Bits 7 6 5 4Meanina 

0 0 0 0 Unspecified 

0 0 0 1 PSTN 

0 0 10 ISDN 

0 0 11 GSM PLMN 

0 10 0 DECT local network 

1 0 0 OCSPDN 
10 0 1 PSPDN 
1 0 1 0 Internet 

10 11 Local Area Networks 
1 1 0 OB-ISDN 

1111 Reserved for extension 
All other values reserved. 

TE-network interface (octet 5a): 
Bits 3 2 1 Meaning 

0 0 0 Not defined 

10 0 Standard interface 

All other values reserved. 
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External service type (octet 5b): 
Bits 7 6 5 4 3 2 1 Meaning 

0 0 0 0 0 0 0 Not specified 

0 0 0 0 0 0 1 Any method 

0 0 0 0 0 1 0 Address based IWU selection 

000001 1A message handling facility 
0 0 0 0 1 0 0 Physical 

0 0 0 1 0 0 0 Voice telephone 

0 0 0 1 0 0 1 Telex 

0 0 0 1 0 1 0 Teletex 

0 0 0 1 0 1 1 Facsimile group 3 

0 0 0 1 1 0 0 Facsimile group 4 

0 0 0 1 1 0 1 Videotex (T.IOO/T.IOI) 

0 0 1 0 0 0 0 ERMES 

0 0 1 0 0 0 1 National paging 

0 0 1 0 0 1 O UCI (ETS 300 133-3) 

0 0 1 0 0 1 1 GSM SMS 

0 0 1 0 1 0 0 DECT MMS 

0 0 10 10 1 DECT LRMS 

0 0 10 1 10 IA5 terminal 

0 0 1 0 1 1 1 X.400 message handling 

0 1 0 0 0 0 0 FTP 

0 1 0 0 0 0 1 HTTP 

0 1 0 0 0 1 0 Gopher 

0 1 0 0 0 1 1 News 

0 1 0 0 1 0 0 News/NNTP 

0 10 0 10 1 Telnet 

0 10 0 1 1 0 Wide area info server 

0 10 0 1 1 1 Host specific file names 

0 1 0 1 0 0 0 Prospero 

All other values reserved. 
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LLC identity (octet 6): 

Bits 7 6 Meaning 

0 1 octet identifier 
All other values reserved. 


LLC coding indicator (octet 6): 

Bits 5 4 3 2 1 Meaning 

X X X X 1 LLC Information transfer attributes present 
X X X 1 X LLC Access attributes present 
X X 1 X X User information layer 1 protocol ID present 
X 1 X X X User information layer 2 protocol ID present 
1 X X X X User information layer 3 protocol ID present 
All other values reserved. 


Information transfer capability (octet 6a): 
Bits 5 4 3 2 1 Meaning 
0 0 0 0 0 Speech 

0 1 0 0 0 Unrestricted digital information 

0 10 0 1 Restricted digital information 

1 0 0 0 0 3,1 kHz audio 
1 0 0 0 1 7,0 kHz audio 
10 10 0 Fax 

1 1 0 0 0 Video 

All other values reserved. 


Transfer mode (octet 6b): 
Bits 7 6 Meaning 

0 0 Circuit mode 

1 0 Packet mode 

1 1 None (no transfer mode required) 
All other values reserved. 
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Information transfer rate (octet 6b and 6e): 


Bits 5 4 3 2 1 


0 0 0 0 0 

Packet mode calls 

0 10 10 

1 6 kbps 

0 10 11 

32 kbps 

1 0 0 0 0 

64 kbps 

1 0 0 0 1 

2 X 64 kbps 

10 0 11 

384 kbps 

11110 

Unspecified 

11111 

Defined by rate multiplier 

All other values reserved. 


NOTE 1: When octet 5c is omitted, the transfer rate is symmetric. When 
octet 5c is included, the rate in octet 5 refers to the direction 
Orig=>Dest, and the rate in octet 5c refers to the reverse 
direction. 

If the reserved coding "defined by rate multiplier" is used, then octet 5a shall 
follow. Octet 5d shall also follow if octet 5c is used (i.e. for asymmetric rates). 
Structure (octet 5b) 

7 6 5 Meaninc 

0 0 0 Default 

0 0 1 8 kHz integrity 

10 0 SDU integrity 

111 Unstructured 

All other values reserved. 

If octet 5b is omitted, or the structure field is coded "default" the structure 
attribute shall be defaulted according to the following table: 

Transfer mode Transfer capability Structure 

circuit speech 8 kHz integrity 
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8 kHz integrity 
8 kHz integrity 
8 kHz integrity 
8 kHz integrity 
8 kHz integrity 
SDU integrity 

Configuration (octet 6d): 
Bits 4 3 Meaning 

0 0 point-to-point 

All other values reserved. 

Establishment (octet 6d): 
Bits 2 1 Meanino 

0 0 demand 

All other values reserved. 

Unit rate (octet 6c and 6): 

Bits 7 6 Meaning 

0 1 16 kbps steps 

1 0 32 kbps steps 
11 64 kbps steps 
All other values reserved. 

Rate multiplier (octet 5a and 5d): 
Bits 5 4 3 2 1 Meaning 

0 n n n n Number of steps 

All other values reserved. 

NOTE 2: The number of steps (nnnn) relates to the unit rate defined in the 
same octet. The value is coded with the natural binary value, 


circuit restricted digital 

circuit 3,1 kHz audio 

circuit 7,0 kHz audio 

circuit fax 

circuit video 

packet unrestricted digital 
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with the least significant bit in bit position "1". Allowable values 
for "number of steps" are "1" to "15". 

Symmetry (octet 5c): 
Bits 7 6 Meaninc 

0 0 bidirectional symmetric 

1 O unidirectional asymmetric 
1 1 bidirectional asymmetric 
All other values reserved. 

Rate adaption (octet 6): 
Bits 5 4 Meaninc 

0 0 no rate adaption 

0 1 V.11 0/X.30 rate adaption 

1 0 CCITT X.31 flag stuffing 
All other values reserved. 


Signalling access protocol (octet 7): 
Bits 5 4 3 Meaning 

0 0 1 1.440/450 

0 1 0 X.21 

0 1 1 X.28 - dedicated PAD, individual NUI 

1 0 0 X.28 - dedicated PAD, universal NUI 
1 0 1 X.28 - non dedicated PAD 

1 1 0 X.32 

All other values reserved. 

Synchronous/asynchronous (octet 7) 
1_ Meaninc 

0 synchronous 

1 asynchronous 
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Negotiation (octet 7) 

Bits 6 Meaning 

0 in-band negotiation not possible 

All other values reserved. 


NOTE: See Rec. V.110 and X.30 

User rate coding (octet 7a): 
Bits 7 6 5 4 3 2 1 Meaning 

0 0 0 0 0 0 1 0,6 kbps; 

0 0 0 0 0 1 0 1,2 Icbps; 

0 0 0 0 0 1 1 2,4 kbps; 

0 0 0 0 1 0 0 3,6 kbps: 

0 0 0 0 1 0 1 4,8 kbps; 

0 0 0 0 1 1 0 7,2 kbps; 

0 0 0 0 1 1 1 8,0 kbps; 

0 0 0 1 0 0 0 9,6 kbps; 

0 0 0 1 0 0 1 14,4 kbps; 

0 0 0 1 0 1 0 16 kbps; 

0 0 0 1 0 1 1 19,2 kbps; 

0 0 0 1 1 0 0 32 kbps; 

0 O O 1 1 1 0 48 kbps; 

0 0 0 1 1 1 1 56 kbps; 

0 01 0 0 0 0 64 kbps; 

0 0 1 0 1 0 1 0,1345 kbps; 

0 0 1 0 1 1 00,1 kbps; 

0 0 1 0 1 1 1 0,075/1.2 kbps; 

0 0 1 1 0 0 0 1,2/0,075 kbps; 

0 0 1 1 0 0 1 0,050 kbps; 

0 0 1 1 0 1 0 0,075 kbps; 

0 0 1 10 1 1 0,110 kbps; 


V.6 and X.I. 
V.6. 

V.6 and X.I. 
V.6. 

V.6 and X.I. 

V.6. 

1.460. 

V.6 and X.I . (GSM HSCSD) 

V.6. (GSM HSCSD) 

1.460. 

V.6. (GSM HSCSD) 

1.460. (GSM HSCSD) 

V.6 and X.I . (GSM HSCSD) 
V.6. 

X.I. (GSM HSCSD) 

X.I. 

X.I. 

v.6 and X.I. (NOTE 5) 
V.6 and X.I. (NOTE 5) 
V.6 and X.I. 
V.6 and X.I. 
V.6 and X.I. 
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U U 1 

1 


v.D ana a. i . 

U U 1 

1 


v,o ana a, i , 

u U 1 

•1 
1 


V.D ana a. i . 

U U 1 

1 

1 1 1 1 ^ KDpS, 

v.D. 

XXX 

X 

XXX Z0,0 KDpS, 

(VjoIVi MbUbD) 

XXX 

X 

XXX oo,*l- KDpS, 

(vjoM nbUbU) 

XXX 

X 

XXX 57,6 kbps; 

(GSM HSCSD) 

XXX 

X 

XXX 67,2 kbps; 

(GSM HSCSD) 

XXX 

X 

XXX 76,8 kbps; 

(GSM HSCSD) 

XXX 

X 

X X X 96 kbps; 

(GSM HSCSD) 


All other values reserved. 

NOTE 5: The first rate is the transmit rate in the forward direction of the 
call. The second rate is the transmit rate in the backward 
direction of the call. 

NOTE 6: See recommendations for CCITT X-series and CCITT 1.460. 

Intermediate rate (interm rate) (octet 7b): 
Bits 7 6 Meaning 
0 0 Not used 

0 1 8 kbps 
10 16 kbps 

1 1 32 kbps 

Network Independent Clock on transmission (NIC tx) (octet 7b): 
Bits 5 Meaning 

0 Not required to send data with network independent clock 

1 Required to send data with network independent clock 

NOTE 7: NIC tx refers to transmission in the forward direction of the call. 
NOTE 8: See CCITT Recommendations V.I 10 and X.30. 
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Network independent Clock on reception (NIC rx) (octet 7b): 
Bits 4 Meaning 

0 Cannot accept data with Network independent clock 

1 Required to send data with Network independent clock 

NOTE 9: NIC rx refers to transmission in the backward direction of the 
call. 

NOTE 10: See CCITT Recommendations V.1 10 and X.30. 

Flow-Control on transmission (F-C tx) (octet 7b): 
Bits 3 Meaning 

0 Not required to send data with flow control mechanism 

1 Required to send data with flow control mechanism 


NOTE 1 1 : F-C tx refers to transmission in the forward direction of the call. 

Flow-Control on reception (F-C rx) (octet 7b): 
Bits 2 Meaning 

0 Cannot accept data with flow control mechanism (i.e. 
sender does not support this optional procedure); 

1 Can accept data with flow control mechanism (i.e. sender 
does support this optional procedure); 

NOTE 12: F-C rx refers to transmission in the backward direction of the 
call. 

Stop bits coding (octet 7c): 
Bits 7 6 Meaning 
0 0 Not used 

0 1 1 bit 
10 1,5 bits 

1 1 2 bits 
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Data bits coding (octet 7c): 
Bits 5 4 Meaning 
0 0 Not used 

0 1 5 bits 

1 0 7 bits 
1 1 8 bits 

Parity coding (octet 7c): 
Bits 3 2 1 Meaning 

0 0 0 Odd 

0 10 Even 

0 1 1 None 

10 0 Forced to 0 

1 0 1 Forced to 1 

All other values reserved. 

Duplex mode (Dup) (octet 7d): 
Bits 7 Meaning 

0 Half duplex 

1 Full duplex 

Modem type (octet 7d): 
Bits 6 5 4 3 2 1 Meaning 


0 0 0 0 0 0 

Reserved 

0 0 0 0 0 1 

V.21 

0 0 0 0 1 0 

V.22 

0 0 0 0 1 1 

V.22 bis 

0 0 0 1 0 0 

V.23 

0 0 0 10 1 

V.26 

0 0 0 1 1 0 

V.26 bis 

0 0 0 1 1 1 

V.26 ter 

0 0 10 0 0 

V.27 
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0 0 1 0 0 1 V.27 bis 
0 0 10 10 V.27 ter 
0 0 10 1 1 V.29 
0 0 1 1 0 0 V.32 
0 0 1 10 1 V,35 
X X X X X X V.32 bis 
X X X X X X V.34 

100000 to } Reserved for national use 

111111 } 

All other values reserved. 

NOTE 13:CC!TT V-series Recommendations 


User information layer 1 protocol (octet 8): 
Bits 7 6 5 4 3 2 1 Meaning 

0 0 0 0 0 0 0 default layer 1 protocol 

All other values reserved. 


User information layer 2 protocol (octet 8a): 


Bits 5 4 3 2 1 

Meanina 

0 0 0 0 0 

User specific (escape) 

0 0 0 0 1 

Basic mode ISO Publication 1745 

0 0 0 1 0 

CCITT Recommendation Q. 921/1.441 (LAP.D) 

0 0 110 

CCITT Recommendation X.25; link layer (LAP.B) 

0 0 111 

CCITT Recommendation X.25 multilink 

0 10 0 0 

Extended LAP.B 

0 110 0 

ISO Publication 8802/2 (LAN LLC) 

1 0 0 0 1 

ISO Publication 8802/x [33] (NOTE 7) 

10 0 10 

GSM Recommendation 04.06) 

10 110 

CCITT Recommendation V.42 (LAP.M) 
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1 1 0 0 0 ISO 6429. codeset 0 (DC1/DC3) 
1 1 0 0 1 X.75 layer 2 modified (teletex) 
110 10 videotex profile 1 

1110 0 COPnoFlCt (Character oriented Protocol with no Flow 

Control mechanism) 
1110 1 Internet Protocol 
All other values reserved. 

NOTE 4: ISO Publication 8802/x refers to LAN operation with a null Layer 
2 protocol (LLC not implemented). 


User information layer 3 protocol (octet 8b): 
Bits 5 4 3 2 1 Meaning 

0 0 0 0 0 User specific (escape) 

0 0 0 1 0 ETS 300 102 

0 0 110 CCITT Recommendation X.25 packet layer 

0 0 111 ISO Publication 8208 (CCITT Recommendation X,25 packet 

level for DTE) 

0 1 0 0 0 ISO Publication 8348 (OSI C/O protocol) 

0 10 0 1 ISO Publication 8473 (OSI C/L service) 

0 10 10 CCITT Recommendation T.70, minimum network layer 

10 0 10 GSM Recommendation 04.08 

0 0 0 0 1 Transmission Control Protocol 
All other values reserved. 

HLC Identity (octet 9): 

Bits 7 6 Meanino 

1 0 octet group identifier 
All other values reserved. 


HLC coding indicator (octet 9): 
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Bits 5 4 3 2 1 Meaning 

X X X X 1 User protocol ID present 

X X X 1 X User infornnation layer 4 protocol ID present 

X X 1 X X User information layer 5 protocol ID present 

X 1 X X X User infornnation layer 6 protocol ID present 

1 X X X X User information layer 7 protocol ID present 

User protocol ID (octet 9a): 

Bits 5 4 3 2 1 Meanino 

0 0 0 0 0 User specific (escape) 

0 0 0 0 1 V.I 10/X.30 rate adaption (NOTE 6) 

0 0 0 1 0 G.711 //-law PCM 

0 0 0 1 1 G.71 1 A-law PCM 

0 0 1 0 0 G.721 ADPCM 

0 0 10 1 H.221 and H.242 

0 0 110 H.261 Video 

0 0 111 Non-standard rate adaption 

0 1 0 0 0 V.I 20 rate adaption 

0 10 0 1 X.31 rate adaption 

1 0 0 0 0 Group 3 fax 
1 0 0 0 1 Group 4 fax 
1 1 0 0 0 X.28/X.29 

10 0 10 GSM Recommendation 03.40, SM-TP messages [xx] 

10 0 11 CCITT Recommendation X.400 messages [yyl 

10 10 0 Internet RFC 822 or MIME messages [zz] 

110 0 1 DECT LRMS/MMS protocol (MMSP) 
All other values reserved. 


NOTE 3: If octet 6 indicates "V.n0/X.30 rate adaption", the set-up 
message is also required to contain the << END-TO-END- 
COMPATIBILITY > > element to define the attributes of the rate 
adaption service. 
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User information layer 4 protocol (octet 9b): 
Bits 5 4 3 2 1 Meanino 
All other values reserved. 

User information layer 5 protocol (octet 9c): 
Bits 5 4 3 2 1 Meaning 
All other values reserved. 

User information layer 6 protocol (octet 9d): 
Bits 5 4 3 2 1 Meanino 
All other values reserved. 

User information layer 7 protocol (octet 9e): 
Bits 5 4 3 2 1 Meanino 
All other values reserved. 

QoS identity (octet 10): 
Bits 7 6 Meaning 

1 1 octet group identifier 

All other values reserved. 

The purpose of the << FACILITY >> information element (see Subclause 
7.7.15 in ETS 300 175-5 2nd edition) is to indicate the invocation and 
operation of supplementary services, identified by the corresponding operation 
value within the < <FACILITY> > information element (see figure 30). 

Service discriminator coding: 
Bits 5 4 3 2 1 Meaning 

1 0 0 0 1 Discriminator for supplementary service applications 
10 0 10 Discriminator for Multimedia Messaging service aoDlications 
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All other values are reserved. 
Other fields are coded as indicated below. 

The purpose of the < <CALLED-PARTY-NUMBER> > element (see Subclause 
7.7.7 in ETS 300 175-5 2nd edition)is to identify the called party of a call in an 
en-bloc fornnat (see figure 31). 

Number type (octet 3): 

Bits 7 6 5 Meaning 
0 0 0 Unknown 
0 0 1 International number 
0 10 National number 
Oil Network specific number 
10 0 Subscriber number 
10 1 Server number 

110 Abbreviated number 

111 Reserved for extension 
All other values reserved. 

Numbering plan identification (octet 3): 
Bits 4 3 2 1 Meaning 
0 0 0 0 Unknown 

0 0 0 1 ISDN/telephony plan Rec. E,164/E.163 

0 0 11 Data plan Rec. X.I 21 

1 0 0 0 National standard plan 
10 0 1 Private plan 

1 0 1 OIP Address 

10 1 1 IP Address Character format (URI) 
1 1 0 0X.400 address 
1 1 0 1 URI 
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1 1 1 OLAN address 

1111 Reserved for extension 

All other values reserved. 

NOTE: DECT characters are specified below. They are based on 
characters. 
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MMS protocol element 


Bits 


8 

7 1 6 

5 1 4 1 

3 

2 1 

1 1 

vjcteT. 

0 

< <MMS protocol element > > 

1 

Length of Contents (L) 

*> 

1 

MMS Action type 

Rep. 

Esc 

o 
o 

0/1 

MMS sequence number 


1 

MMS sequence numbering (extension) 

4a 

0/1 

Service type 

5 

0/1 

Service subtype 

Transmission 

6 




type 




0/1 

Data content type 

7 

0/1 

Action result 

o 
O 

0/1 

Command type 

Q 

0/1 

Information type 

10 

0/1 

Command object 

11 

0/1 

Command object (extension) 

11a 

0/1 

User data length 

12 

0/1 

User data length (extension) 

12a 

0/1 

User data length (extension) 

12b 

1 

User data length (extension) 

12c 


MMS action type (octet 3): 

Bits 7 6 5 4 Meaning 

0 0 0 1 MMS-SEND 

0 0 1 OMMS-SEND-RPY 

0 0 11 MMS-RECEIVE 
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0 1 0 OMMS-RECEIVE-RPY 

1 0 0 OMMS-CONTROL 

10 0 1 MMS-CONTROL-RPY 
1 0 1 OMMS-STATUS 
10 11 MMS-STATUS-RPY 
All other values reserved. 

Reply requested (octet 3): 
Bits 3 2 Meanino 

X 0 Reply not requested from MMS entity 

X 1 Reply requested from MMS entity 

0 X Reply not requested from end entity 

1 X Reply requested from end entity 
All other values reserved. 

Escape command present (octet 3): 
Bits 1 Meaning 

0 Escape command not present 

1 Escape command present 
All other values reserved 

MMS sequence number (octet 4): 

Coded as natural binary value. Value 0 is reserved for general use. 
Extended MMS sequence number (octet 4a): 

Coded as octet 4. This octet is optional. The complete MMS sequence number 
is a combination of both octets. 


Service type (octet 5): 
Bits 7 6 5 4 3 2 1 Meaning 
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0 0 0 0 0 0 0 Not specified 
0 0 0 0 0 0 1 Any method 

0 0 0 0 0 1 0 Address based IWU selection 

000001 1A message handling facility 
0 0 0 0 1 0 0 Physical 

0 0 0 1 0 0 0 Voice telephone 

0 0 0 1 0 0 1 Telex 

0 0 0 1 0 1 0 Teletex 

0 0 0 1 0 1 1 Facsimile group 3 

0 0 0 1 1 0 0 Facsimile group 4 

0 0 0 1 1 0 1 Videotex (T.I 00/T.101 ) 

0 0 1 0 0 0 0 ERMES 

0 0 1 0 0 0 1 National paging 

0 0 1 0 0 1 0 UCI (ETS 300 133-3) 

0 0 1 0 0 1 1 GSM SMS 

0 0 1 0 1 0 0 DECT MMS 

0 0 10 10 1 DECT LRMS 

0 0 10 110 IA5 terminal 

0 0 1 0 1 1 1 X.400 message handling 

0 1 0 0 0 0 0 FTP 

0 1 0 0 0 0 1 HTTP 

0 1 0 0 0 1 0 Gopher 

0 1 0 0 0 1 1 News 

0 1 0 0 1 0 0 News/NNTP 

0 10 0 10 1 Telnet 

0 10 0 110 Wide area info server 

0 10 0 1 1 1 Host specific file names 

0 1 0 1 0 0 0 Prospero 

All other values reserved. 


Service subtype (octet6): 
Bits 7 6 5 4 Meaning 
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0 0 0 O Undefined 
0 0 0 1 Standard 

Telex: 
0 0 0 1 Standard 
110 OVia teletex conversion 

Teletex: 


0 0 

0 

1 Standard 

0 0 

1 

OOper. doc. 

0 0 

1 

1 Monit doc 

0 1 

0 

OCtrl doc. 

0 1 

0 

1 TFT of Doc. tr. Mode 

0 1 

1 

OTFT of Binary File Tr. 

0 1 

1 

1 TFT of Edifact 

1 0 

0 

Oin PSPDN 

1 0 

0 

1 in CSPDN 

1 0 

1 

Oin analog PSTN 

1 0 

1 

1 in digital ISDN 


Facsimile group 3: 

0 0 0 1 Standard 

1 1 01 TFT of Basic tr.Mode 
0 10 1 TFT of Doc. tr. Mode 
0 1 1 OTFT of Binary File Tr. 
0 111 TFT of Edifact 

Facsimile group 4: 
0 0 0 1 Standard 
0 0 1 OOper, doc. 
0 0 11 Monit doc 
0 10 OCtrl doc. 
0 10 1 TFT of Doc. tr. Mode 
Oil OTFT of Binary File Tr. 
0 111 TFT of Edifact 
All other values reserved. 
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These values are related to the Service type field i.e. not all listed values are 
possible with all service type options. The service options related to the value 
of the Service type is defined. {TFT; Telematic File Transfer). 

Message transmission type (octet 6): 

Bits 3 2 1 Meanino 

0 0 1 Unspecified 

0 10 Encapsulated 

0 1 1 Multipart 

1 0 0 Body in U-pIane 
10 1 Header in C-plane 
1 1 0 Normal 

All other values reserved. 

Message content type (octet 7): 
Bits 7 6 5 4 3 2 1 Meaning 


0 

0 0 

0 

0 

0 

0 Undefined 

0 

0 0 

0 

0 

0 

1 Specified by the service type 

0 

0 0 

0 

0 

1 

0 Local type 

0 

0 0 

0 

0 

1 

1 Simple formattable document 

0 

0 0 

0 

1 

0 

0 Basic text 

0 

0 0 

0 

1 

0 

1 lA 5 text (T.50) 

0 

0 0 

0 

1 

1 

0 Telex 

0 

0 0 

0 

1 

1 

1 Teletex (T.61) 

0 

0 0 

1 

0 

0 

0 Videotex (T.IOO/T. 101) 

0 

0 0 

1 

0 

0 

1 Image 

0 

0 0 

1 

0 

1 

0 TIFF image 

0 

0 0 

1 

0 

1 

1 GIF image 

0 

0 0 

1 

1 

0 

0 JPEG image 

0 

0 0 

1 

1 

0 

1 Fax G 4 class 1 
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0 

0 

0 1 

1 

1 

0 Fax G 3 (T.4/T.30) 

0 

0 

1 

0 

0 

0 

0 Audio 

0 

0 

1 

0 

0 

0 

1 AVI audio 

0 

0 

1 

0 

0 

1 

0 Multipart: mixed 

0 

0 

1 

0 

0 

1 

1 Multipart: parallel 

0 

0 

1 

0 

1 

0 

0 Multipart: alternative 

0 

0 

1 

0 

1 

0 

1 Multipart: digest 

0 

0 

1 

0 

1 

1 

0 Encapsulated: RFC 822 or MIME 

0 

0 

1 

0 

1 

1 

1 Encapsulated: GSM SMS 

0 

0 

1 

1 

0 

0 

0 Encapsulated: X.400 

r\ 
\J 

xJ 

1 

1 

\J 

VJ 

1 ^cici siream appiicaiion 

0 

0 

1 

1 

0 

1 

0 Postscript application 

0 

0 

1 

1 

0 

1 

1 Video 

0 

0 

1 

1 

1 

0 

0 MPEG video 

0 

0 

1 

1 

1 

0 

1 AVI video 


All other values reserved. 

This field specifies the content of the message i.e. the format of the message 
content. 

Action result (octet 8): 

Bits 7 6 5 4 3 2 1 Meaning 

Successful transactions: 
0 0 0 0 0 0 0 Message received by server 
0 0 0 0 0 0 1 Message sent to end entity 
0 0 0 0 0 1 0 Message replaced by the server 
0 0 0 0 0 1 1 Message received by end entity 

Temporary Error: 
0 1 0 0 0 0 0 Congestion 
0 1 0 0 0 0 1 End entity busy 
0 1 0 0 0 1 0 No response from end entity 
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0 1 

0 

0 10 0 Quality of service not available 

0 1 

0 

0 10 1 Error in end entity 

0 1 

0 

0 1 1 0 No nnemory available 



Permanent Error: 

1 0 

0 

0 0 0 1 Invalid address 

1 0 

0 

0 0 11 Invalid network(End User not accessible) 

1 0 

0 

0 0 10 End entity not available 

1 0 

0 

0 10 1 Secondary interworking failed 

1 0 

0 

0 110 Primary interworking failed 

1 0 

0 

0 111 Incompatible file type 

1 0 

0 

1 0 0 0 Service rejected 



General values: 

1 0 

0 

0 0 0 0 Command successful 

1 0 

0 

0 0 0 1 Command unsuccessful 

1 0 

0 

0 0 10 Successful 

1 0 

0 

0 0 11 Unsuccessful 


All other values reserved. 


Command type (octet 9): 

Bits 7 6 5 4 3 2 1 Meaninc 

Message related: 
0 0 0 0 0 0 0 Status Enquiry 
0 0 0 0 0 0 1 Cancel status enquiry 
0 0 0 0 0 1 0 Delete 
0 0 0 0 1 0 0 Replace 
0 0 0 0 1 0 1 Memory available 
0 0 0 0 1 1 0 Cancel 

Connection related: 
0 0 1 0 0 0 0 Login 
0 0 1 0 0 0 1 Logout 
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All other values reserved. 


information type (octet 10): 


Bits 7 6 5 4 3 2 1 Meanino 

0 0 0 0 0 0 0 Status report 

0 0 0 0 0 0 1 Message/file waiting in server 

All other values reserved. 


Command object (octet 11.. 11a): 


Coded as MMS sequence numbering 


User data length (octet 12, 12a, 12b, 12c): 

Coded as natural binary value indicating the amount of octets in the user data 
field. 


Time/Date element 


Bits 


8 


< < Time/Date > > 


Length of Contents (L) 


Year 


Month 


Day 


Hour 


Minute 


Octet: 
1 
2 
3 
4 
5 
6 
7 


Second 


8 
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Time zone 


9 


Time/date coding: 


Year: Month: Day: 


Hour: 


Minute: 


Second: 


Time Zone 


Digits: 


2 


2 


2 


2 


2 


2 


2 


(Semi-octets) 

The Time Zone indicates the difference, expressed in quarters of an hour, 
between the local time and GMT. In the first of the two semi-octets, the first bit 
(bit 3 of the seventh octet of the TP-Service-Centre-Time-Stamp field) 
represents the algebraic sign of this difference (0 : positive, 1 : negative). 
The Service-Centre-Time-Stamp, and any other times coded in this format, 
represents the time local to the sending entity. The Time Zone code enables 
the receiver to calculate the equivalent time in GMT from the other semi-octets 
in the Service-Centre-Time-Stamp, or Indicate the time zone {GMT, GMT-J-IH 
etc.), or perform other similar calculations as required by the implementation. 

The purpose of the < < ALPHANUMERIC> > element (see Subclause 7.7.3 in 
ETS 300 175-5 2nd edition) is to provide a transport mechanism for a family of 
alternative characters in both directions. 

NOTE: This element shall not be used to carry dialing information. 
This element shall not be used to carry dialling information (see figure 32), 

Character type coding: 

Value Meaning 
Bits 7 6 5 (Character tvoel 

0 0 1 Standard 8-bit characters 

0 10 Standard 4-bit characters 
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Oil Standard 7 bit charaters 

10 0 Binary 

10 1 Connpressed 

110 Encrypted 

1 1 1 Others 
All other values reserved. 
Odd/even coding: 
Bits 4 Meaning 

0 Even number of characters 

1 Odd number of characters 


NOTE: The odd/even flag shall only be used when the character type is 
4 bit. In all other cases it should be set to "even". 

Standard 8-bit character set coding 
Character set coding: 

Value Meaning 
Bits 3 2 1 (Character set) 

0 0 0 Reserved 

0 0 1 DECT standard 8 bit 

0 10 8 bit ASCII 

0 1 1 US-ASCII 

10 0 ISO 8859 

10 1 8 bit EBCDIC 


All 8-bit characters shall always be coded with one character per octet. Multiple 
characters shall be interpreted in the order of ascending octet numbers. 


Standard 4-bit character set coding 
Character set coding: 
Value Meaning 
Bits 3 2 1 (Character set) 
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0 0 0 Reserved 

0 0 1 WCPE standard 4-bit characters (Annex D) 

1 0 0 ERMES 4-bit characters (ANSimA Standard [27]) 
All other values reserved. 

4-bit characters shall always be coded with two characters per octet. Multiple 
characters shall be interpreted in the order of ascending octet numbers, and 
within each octet the high placed character (bits position 5-8) first. 

7 bit characters set coding 
Character set coding: 

Value Meaning 
Bits 3 2 1 (Character set) 

0 0 0 7 bit ERMES 

0 0 1 7 bit standard ASCII 

0 10 7 bit ASCII (IA5/T.50) 

All other values reserved. 

Others characters set coding 
Character set coding: 

Value Meaning 
Bits 3 2 1 (Character set) 

000 ASN.1.BER.1 

0 0 1 User specific 

0 10 National variations of IRA 

All other values reserved. 

Compressed characters set coding 
Character set coding: 

Value Meaning 
Bits 3 2 1 (Character set) 

0 0 0 ZIP 
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O 0 1 V.42 bis 

All other values reserved. 

Encrypted characters set coding 
Character set coding: 

Value Meaning 
Bits 3 2 1 (Character set) 

All other values reserved. 

The language coding defined in octet 5 is optional. The coding is done as 
specified in GSM 03.38. 

The purpose of the << SERVICE-CHANGE-INFO > element (see Subclause 
7.7.38 in ETS 300 175-5 2nd edition) is to indicate the attributes of the 
proposed service change (see figure 33). 

Coding standard: 
Bits 7 6 Meaning 

0 0 DECT standard coding 

All other values reserved. 

M (Master) coding: 

Bits 5 Meanino 

0 Initiating side is master 

1 Receiving side is master 

Change mode coding: 
Bits 4 3 2 1 Meaning 
0 0 0 ONone 

0 0 0 1 Connection Reversal 

0 0 1 0 Bandwidth change (NOTE 1) 

0 1 0 0 Rerouting (of U-plane links) (NOTE 1) 
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0 1 1 0 Rerouting plus bandwidth change (NOTE 1) 

1 0 0 0 Suspend 

10 0 1 Resume 

1111 Reserved for extension (NOTE 2) 
All other values reserved. 

NOTE 1: Additional information elements shall be included in the message when 
indicating "bandwidth change" or "rerouting". Refer to subclause 9.6. NOTE 2: 
When using the reserved value, octet 3a shall follow containing extended 
coding of the service change. NOTE 3:0ctet 4 shall only appear for "suspend" 
and "resume" codings. Octet 4 shall only appear for "suspend" and "resume" 
codings. 

Extended change mode: 

Extended change mode is reserved for further standardisation. 

A attributes coding: 
Bits 7 6 5 Meaning 

0 0 0 Not applicable 

0 10 Maintain old connection(s) 

011 Release old connection(s) 
Reset (R) coding: 

Bits 4 Meaninc 

0 Do not reset state variables 

1 Reset state variables 
B attributes coding; 

Bits 3 2 1 Meaning 

0 0 0 Not applicable 

0 10 Interrupt data transfer 

Oil Maintain data transfer 
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The purpose of the << FEATURE-ACTIVATE > > information element (see 
Subclause 7.7.16 in ETS 300 175-5 2nd edition) is to activate a feature as 


identified in the feature field (see figure 34). 


Feature coding (octet 3): 


Bits 7 6 5 4 3 2 1 Meanino 

Parameter 

0 0 0 0 0 0 1 register recall 

no 

0 0 0 1 1 1 1 external handover switch 

no 

0 1 0 0 0 0 0 queue entry request 

no 

0 1 1 0 0 0 0 indication of subscriber number 

no 

1 0 0 0 0 1 0 feature key 

yes 

1 0 0 0 1 0 0 specific line selection 

yes 

1 0 0 0 1 1 1 specific trunk carrier selection 

yes 

1 0 0 1 0 0 0 control of echo control functions yes 

1 1 0 0 0 0 0 cost information 

yes 

1 1 1 0 0 0 0 MMS messaoina 

no 

All other values reserved. 


The purpose of the << FEATURE-INDICATE > > information element (see 
Subclause 7.7.17 in ETS 300 175-5 2nd edition) is to allow the FT to convey 
feature indications to the user regarding the status of an activated feature (see 


figure 35). 

Feature coding (octet 3) 

Bits 7 6 5 4 3 2 1 Meanino ■ Parameter 

0 0 0 0 0 0 1 register recall no 

0 0 0 1 1 1 1 external handover switch no 

0 1 0 0 0 0 0 queue entry request no 

0 1 1 0 0 0 0 indication of subscriber number no 
10 0 0 0 1 0 feature key yes 

1 0 0 0 1 0 0 specific line selection yes 
1 0 0 0 1 1 1 specific trunk carrier selection yes 
10 0 1 0 0 0 control of echo control functions yes 
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1 1 0 0 0 0 0 cost information yes 

1 1 1 0 0 0 0 MMS nnessaQinq no 

All other values reserved. 


The purpose of the < <IWU-TO-IWU> > elennent (see Subclause 7.7.23 in ETS 
300 175-5 2nd edition) is to encapsulate any message or information element 
that cannot be interworked into one or more other DECT information 
element(s). 


If the message or element is too large to fit into a single < <IWU-TO-IWU> > 
element, it shall be segmented into a series of < <IWU-TO-IWU > > elements 
that are associated using the < < SEGMENTED-INFO > > element (see figure 
36). 

Send/Reject (S/R) bit: 

Bits 7 Meaning 

0 Rejection of message 

1 Transmission of message 

NOTE1: This Send/Reject (S/R) bit is used to distinguish between the 
sending of a new message (e.g. sent in the direction A= >B) and the rejection 
of a received message (e.g. message received by B can be rejected by sending 
"reject" code in direction B = > A). 

Protocol Discriminator (PD): 

Bits 6 5 4 3 2 1 Meaning 

0 0 0 0 0 0 User Specific (NOTE 2) 
0 0 0 0 0 1 OSI high layer protocols 

0 0 0 0 1 0 CCITT Recommendation X.244 [37] (NOTE 3) 
0 0 0 1 0 0 IA5 characters [25] 

0 0 0 1 1 1 CCITT Recommendation V.I 20 Rate adaption 
0 0 1 0 0 0 CCITT Recommendation Q. 931 (1.451), message [30] 
0 0 1 0 0 1 CCITT Recommendation Q.931 (1.451), element(s) [30] 
(NOTE 4) 
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0 0 10 10 CCITT Recommendation Q.931 (1.451), partial message. 
(NOTE 5) 

0 10 0 0 0 GSM Recommendation 04.08, message [22) 

0 10 0 0 1 GSM Recommendation 04.08, element(s) [22] (NOTE 4) 

0 10 0 10 GSM Recommendation 03.40, SM-TP messages [xx] 

0 10 0 1 1 CCITT Recommendation X.400 messages [yy] 

0 10 10 0 Internet RFC 822 or MIME messages [zz] 

111111 Unknown 

All other values reserved. 

NOTE 2:The IWU information is structured as shown below. NOTE 3:The IWU 
information is structured according to CCITT RecommendationX.244[37] 
(CCITT RecommendationX. 25(67] call user data). NOTE 4:lf more than one 
element is included, they are interpreted in the order of appearance. NOTE 5: 
The 0.931(1.451) partial message excludes the protocol discriminator and the 
call 


Rest of the subclause 7.7.23 remains the same. 


The CC-INFOrmation (see Subclause 6.3.2.2 of ETS 300 175-5 2nd edition), 
message is used to transfer additional information between FT and PT both 
during and after call establishment (see figure 37). NOTE 1:The message may 
contain either the < < CALLED-PARTY-NUMBER> > element or the 
< < "KEYPAD" > > element, but not both. NOTE 2: Included if the PT optionally 
indicates completion of "OVERLAP SENDING" to the FT (or if the FT optionally 
indicates completion of "OVERLAP RECEIVING" to the PT). NOTE 3: Address 
elements are only included in messages sent in the "OVERLAP SENDING" state. 
NOTE 4:lncluded if requested as part of external handover. NOTE 5:The 
<< REPEAT-INDICATOR > > information element may optionally be included in 
front of the << FACILITY >> , < <IWU-to-IWU> > and < <PROGRESS 
INDICATOR>> information elements indicating "non-prioritised list". NOTE 
6:The < < IWU-ATTRIBUTES > > element is used only in connection paramter 
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negotiation and the eiennent can only be if <<MMS protocol >> element or 
< < Facility > > element are not present. 

The following illustrates the interworking of the MMS to alternate services. 
Only general interworking is described. 

The interworking can take place in two different ways: a complete interworking 
when the upper protocol layers of the service are conveyed transparently and 
the user may receive the original service or all layers are mapped to the MMS 
and the user receives the original service via MMS service. MMS provides 
capability for both of these. Mapping proposed below give a rough proposal for 
mappings with no details. 

The GSM SMS interworking takes place on the GSM protocol leves of SM-TP 
and SM-RP. The E-data profile is used. When an MMS call is established the 
GSM Short message service center number is received in {CC-SETUP} message 
and it is used in the SM-RP layer messages in the RP-Destination Address field. 
In the case of Mobile terminated messaging the RP-Originating Address 
information is mapped into {CC-SETUP} message << Calling pary number>> 
element. The contents of the SM-TP layer frame is mapped into MMS 
messages. A special case of the RP-SMMA message is conveyed in the MMS- 
COMMAND messages . 

The RP layer ("Successful" in MMS) and TP layer ("End entity received 
message" in MMS) acknowledgements are done with MMS messaging replies. 
Thus the interworking in the GSM case is between MMS and SM-TP and SM-RP 
(see figure 38). 

The interworking of DECT MMS and GSM facsimile group 3 takes place with 
the T.30 fax service. The fax received from PP/outside network is first received 
by the FP, the formed for the other transmission format (T.30 or MMS) and 
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transmited further. The terminal (PP) can disconnect the air interface 
connection after the FP has received the fax and the FP may inform the PP by 
sending a short message through E profile about the successful delivery of the 
fax. Also the FP may inform the PP about incoming fax by short messaging. 
The terminal can the upgrade the E profile connection into a full F-profile fax 
connection to receive the fax transmission (see figure 39). 

The interworking of DECT MMS and PSTN facsimile group 3 takes place with 
the T.30 fax service. The services procedures are as in GSM case but the 
implementation from technical perspective is just like a Local area network fax 
server case. The FP may contain a computer with a fax server card which takes 
care of the fax transmission and reception to/from outside world (see figure 
40). 

The interworking of DECT MMS and internet HTTP (WWW) interworking takes 
place only between HTTP protocol and MMS. During the call establsihment the 
proxy server address is defiend (if needed) in the {CC-SETUP) message. If login 
procedures to the server are needed the MMS control procedures are used. The 
actual MMS commands are mapped into the HTTP commands. The files are 
trasferred through the U-plane connection (F-profile) and the commands 
through C plane (see figure 41). 

The interworking of DECT MMS and internet FTP takes place only between FTP 
protocol and MMS. During the call establishment the FTP server address 
{Internet address) is defined (if needed) in the {CC-SETUP} message. If login 
procedures to the server are needed the MMS control procedures are used. The 
actual MMS commands are mapped into the HTTP commands. The files are 
trasferred through the U-plane connection (F-profile) and the commands 
through C plane (see figure 42). 

The interworking of DECT MMS and X.400 takes place between X.400 P3/P.7 
protocols and MMS. In this case the User Agent (UA) can be in the PP. Thus 
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the MMS replaces the P3/P7 protocol in the air interaface. The body part of the 
mail is trasferred through the U-plane connection (F-profile) and the protocol 
control information through the C-plane (see figure 43). 

The following table classifies the different actions of the alternate message/file 
transfer services for inter>A;orking of messages and proposes a common MMS 
action that could be interworked to the all services. 


MMS 

CCITT 

GSM SMS 

HTTP 

FTP 

X.400 

Comment 

action 

T.611 




{P3) 


MMS- 

SEND 

RP-DATA 

PUT 

STOR 

Message- 

Sending 

SEND 


(SMS- 

POST 

NOOP 

submissio 

message/ 



DELIVER 


and the 

n 

file 



or 


file 

Probe- 




SMS- 



submissio 




SUBMIT) 



n 







Message- 







delivery 


MMS- 

SEND 

RP-ERROR 

HTTP 

FTP 

Message- 

The 

SEND- 

response 

(SMS- 

response 

reply 

submissio 

acknowledge- 

RPY 


DELIVER- 



n Result 

ment of the 



REPORT 




transmission 



or 







SMS- 







SUBMIT- 







REPORT) 







or 







RP-ACK 
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MMS- 

RECEIVE 

- 

GET 

RETR 

X.400 P7 

Fetching a 

RETRI 



HEAD 


has this 

file or 

EVE 





feature 
(FETCH) 

message 

MMS- 

RECEIVE 

- 

HTTP 

FTP 

X.400 P7 

The response 

RETRI 

response 


response 

reply 

has this 

of fetch 

EVE- 




and the 

feature 


RPY 




receive 
d file 

(FETCH) 


MMS- 

TRACE 

RP-DATA 

DELETE 

USER 

Cancel- 

Control 

COM 

delete. 

(SMS- 

LINK 

QUIT 

deferred- 

info to 

MAN 

copy. 

COMMAN 

UNLINK 

PORT 

delivery 

control the 

D 

cancel, 

D) 


TYPE 

Submissio 

remote 


purge. 

RP-SMMA 


MODE 

n-control 

file/message 


reschedu 



STRU 

Register 

or to 


le. 




Change- 

receive/send 


dispatch 




credential 
s 

Report- 
delivery 

status/control 
information 

MMS- 


RP-DATA ( 





STAT 


SMS- 





US 


STATUS- 
REPORT) 
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MMS- 

TRACE 

RP-ERROR 

HTTP 

FTP 


Acknowledge 

COM 

response 

( SMS- 

response 

reply 


-ment of the 

MAN 


SUBMIT- 




action 

D-RPY 


REPORT) 





or 


or 





MMS- 


RP-ACK 





STAT 







US- 







RPY 








NOTE: The GSM SMS service requirements are based on the both SM-RP and 
SM-TP layers since the actual funtionality of the GSM short messaging is a 
combination of these both, for instance, the acknowldegement of the SM-TP 
layer messages is done by the SM-RP layer, MMS-SEND action can replace both 
SMS-DELIVER and SMS-SUBMIT since it may convey information to both 
directions. The parenthesis in the column indicate that RP layer message is 
carrying the TP layer message. 

The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-SEND interworking to T.611 Fax, GSM SMS, 
FTP, CCITT X.400 and HTTP, (o) indicates an optional field. 


MMS 

T.611 

GSM 
SMS 

GSM SMS 

HTTP 

FTP 

X.400 
(P3) 

MMS- 
SEND 

SEND 

SMS- 
DELIVER 

SMS- 
SUBMIT 

PUT 

STOR 

Message- 
submissio 
n 

USER 

CONTROL 

PART 
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Action 
type 

Function 

TP- 
Message 
-Type- 
Indicator 

TP- 

Message- 

Type- 

Indicator 

Method 

Command 

Operation 

Reply 
request 

Sendack 
variation 
is used 
or not 

TP- 

Status- 
Report- 
Indicator 

TP-Status- 
Report- 
Request 

Acknow- 
ledge 
should 
always be 
used 

Acknow- 
ledge 
should 
always be 
used 

Originator- 

report- 

request 

MMS 

sequence 

number 

REQ-ID 

- 

TP- 

Message- 
reference 

Message 
ID 


Message - 
token (o) 

Service 
type 

Service 
ID 

TP- 

Protocol- 
Identifier 

TP- 

Protocol- 
Identifier 

URL 
scheme 


Requested 
-delivery- 
method 

(0) 

Service 
subtype 

Type ID 

TP- 

Protocol- 
Identifier 

TP- 

Protocol- 
Identifier 

- 



Message 

transm.ty 

pe 

- 



Content 
type 

- 

- 

Data 

content 

type 

Convert 

TP- 

Protocol- 
Identifier 

TP- 

Protocol- 
Identifier 

Content- 
Type 
Content- 
subtype 

Type 
coding 
Mode 
coding 

Content- 
Type 

Time 
Stamp 

Send 
time 

TP- 

Service- 
center- 
time- 
stamp 

TP- 

Validity- 
Period 

Date lo) 


Deferred- 
delivery- 
time (o) 


wo 97/10684 


114 


PCT/GB96/02243 


Recipient 
address 

Address 

- 

TP- 

Destinatio 
n-Address 

UR! 


Recipient- 
name 

Sender 
address 

LA-ID ? 

TP- 

Originati 
ng- 

Address 


From 


Originator- 
name 







Segmente 
d info 




Conter)t 
type = 
Multipart 
this is 
used 



USER 
DATA 
PART 







Character 

type 

coding 

APPLI/C 
OM 
header 
Code Id 

TP-Data- 

Coding- 

Sceme 

TP-Data- 

Coding- 

Sceme 

Char set 

Char set 

Encoding 
info type 

Character 
set coding 

APPLI/C 
OM 
header 
Code Id 

TP-Data- 

Coding- 

Scenne 

TP-Data- 

Coding- 

Sceme 

Char set 

Char set 

Encoding 
info type 

Language 
coding 







User data 
length 

File size 

TP-User- 

Data- 

Length 

TP-User- 
Data- 
Length 

Content 
Length 
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User data 

The file 

TP-User- 

TP-User- 

Entity 

The file 

Content 


referred 

Data 

Data 

Body 

referred 



with 




with 



Filename 




Pathname 
in stream 
mode 



The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-SEND-RPY interworking to T.611 Fax, GSM 
SMS, FTP, CCITT X.400 and HTTP, (o) indicates an optional field. 


MMS 

T.61 1 

GSM SMS 

GSM SMS 

HTTP 

FTP 

X.400 (P3) 

MMS- 
SEND- 
RPY 

SEND 
response 

RP- 

ERROR(SMS 

DELIVER/SU 

BMIT- 

REPORT) 

RP-ACK 

HTTP 
response 

FTP 
reply 

Message- 
submission 
-result 

Action 
type 

Function 

RP- 

Message- 

Type- 

Indicator 

RP- 

Message- 

Type- 

Indicator 

Method 


Messge- 

submission 

-identifier 

MMS 

sequen 

ce 

numbe 
r 

REQ-ID 

RP- 

Message- 
Reference 

RP- 

Message- 
Reference 

Message 
ID 



Action 
result 

Status 
Error 

RP-Cause or 
TP -Failure- 
Cause 


Status- 
Code 

Status- 
Code 
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The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-RETRIEVE interworking to T.611 Fax, FTP, 
CCITT X.400 and HTTP, (o) indicates an optional field. 


Field in 

MMS- 

RETIREVE 

T,611 

HTTP 

FTP 

X.400 {P7) 

USER 

CONTROL 

PART 

RECEIVE 

GET 
HEAD 

RETR 

Fetch 

Action type 

Function 

Method 

Command 

Operation 

Reply 
request 

Always 
used 

Always 
used 

Always 
used 

Always 
used 

MMS 

sequence 

number 

REQ-ID 




Service 
type 

Service 




Intermediat 
e server 
address 

Address of 
the Fax 
service in 
the network 

- 

- 

- 

MMS 

sequence 

number 

Filename 

Filename 

Filename 

Item 

Data 

content 

type 

Convert 

Content- 
Type 


Content- 
Type 

Command 
type 
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The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-RETRIEVE-RPY interworking to T.611 Fax, FTP, 
CCITT X.400 and HTTP. |o) indicates an optional field. 


Field in 
MMS- 
RETRIEVE- 
RPY 

T.61 1 

HTTP 

FTP 

X.400 {P7) 

US£ft 

CONTROL 

PART 

RECEIVE 
response 

HTTP 
response 

FTP reply 

Fetch 
result 

Action type 

Function 

Method 


Operation 

MMS 

sequence 

number 

REQ-ID 

Message ID 


Sequence- 
number 

Service type 

Service (o) 




Network 
address 
(address 
type) 

Address (o) 

- 

- 

- 

Message 

transmission 

type 

- 

Content 
type 

- 

- 

Data 

content type 

Type (o) 
Convert 

Content 
type 
Content 
subtype 

Type code 
Mode code 

Content 
type 

Action 
result 

Error 

Status- 
Code 

Status- 
Code 

Entry 
status 
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MMS 

sequence 

number 





Time Stamp 

Send time 
(o) 

Date (o) 

- 

- 

Segmented 
info 


If Content 
type = 
Multipart 
this is used 



USER DATA 
PART 





Character 
type coding 

APPLI/COM 
header 
Code Id 

Char set 

- 

- 

Character 
set coding 

APPLI/COM 
header 
Code Id 

Char set 

- 

- 

Language 
coding 





User data 
length 

Lerjgth of 
the file 

Content 
Length 


Content- 
length 

User data 

The file 

referred 

with 

Filename 

Entity Body 

The 

Filename 
data in 
stream 
mode 

Content 


The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-COMMAND interworking to T.611 Fax, GSM 
SMS, FTP, CCITT X.400 and HTTP, (o) indicates an optional field. 
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Field in 

T.61 1 

GSM SMS 

GSM SMS 

HTTP 

FTP 

X,400 

iViIVlo- 






(P3/P7) 

POMMAMD 








TRAPF 

OIVI o~ 

nr -OIVIIVIM 

UcLc 1 c 

Ubbn 

uancel- 



^ IVI 1 VI M 1 >i u 


LINK 

QUIT 

deferred- 

PART 




UNLINK 

PORT 

aenvery 






TYPE 

Submissi 






MODE 

on- 






STRU 

control 







Register 







Change- 







credentia 
!<; 







Id 

Report- 







delivery 







Delete 

Action type 

Functio 

TP- 

RP- 

Method 

Comman 

Operatic 


n 

Message- 

Message- 


d 

n 



Type- 

Type 






Indicator 





Reply 

Sendac 

Acknowled 

*■ 

>4c/r/7ow 

Acknowl 

- 

request 

k 

ge should 


ledge 

edge 



varia no 

a/ways oe 


should 

Should 



n is 

used 


a/wa/s 

always 



used or 




be used 



not 






MlVlb 

ncQ-ID 

Tr- 

RP- 

Messag 



sequence 


Message- 

Message- 

e ID 



number 


Reference 

Reference 




Service type 


TP- 


URL 





protocol-ID 


scheme 
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Time Stamp 

Sendti 
me 

- 

- 

Date (o) 

- 

Deferred- 
delivery- 

lllllC \\J 1 

Intermediate 

server 

address 

- 




Host- 
port 


UoSr UaXa 

content 


TP, 

protocol-ID 


type 

Content 

subtype 

i ype 
code 
Mode 
code 

wUi 1 Lci 1 1 

types 

Command 
object (MMS 
seq) 

REQRE 
F 

TP- 

Message- 
Number 


Request 
URI 


Message 

submissi 
on - 

identifier 

Command 
tvoe 

Functio 
n 

TP- 

Command- 
Type 

"Memory 
available 
coding" is 
used. 

Method 

Comman 
d 

Operatic 
n 

Escape 
commands/i 
nformation 
nresent 


TP-User- 
Data- 
Length ' 

TP-User- 

Data- 

Length 




Control data 
length 


TP- 

Command- 
data-length 
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Control data 


TP- 



User 

User 



Command- 



name 

name 







i\ew ano 







Old 







credentia 







Is 


The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-COMMAND-RPY interworking to T.611 Fax, 
GSM SMS, FTP, CCITT X.400 and HTTP, (o) indicates an optional field. 


MMS 

T.61 1 

GSM SMS 

GSM 
SMS 

HTTP 

FTP 

X.400 
{P3) 

MMS- 

COMMAND 
-RPY 

TRACE 
response 

RP-ERROR 
ISMS- 
SUBMIT- 
REPORT) 

RP-ACK 

HTTP 
response 

FTP 

reply 

Operation 
results 

Action type 

Function 

RP or TP 
Message- 
Type- 
Indicator 

RP- 

Message- 

Type- 

Indicator 



Operation 

MMS 

sequence 

number 

REQ-ID 

RP- 

Message- 
Reference 

RP- 

Message- 
Reference 




Time 
Stamp 

Send 
time (o) 






Command 
object 







Command 
type 
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Action 
result 

Error 

RP-Cause 
or TP - 
Failure- 
Cause 

Value of 
"Successf 
ul" of 
MMS is 
used 

Status- 
Code 

Status 
-Code 

Values of 
MMS is 
used to 
indicate 
error or 
success 

Control 
data length 







Control 
data 








The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-STATUS interworking to GSM SMS and X.400. 
(o) indicates an optional field. 


MMS 

GSM SMS 

MMS-STATUS 

SMS-STATUS-REPORT 

Action type 

RP-Message-Type-lndicator 

Reply request 

Acknowledge should always be used 

MMS sequence number 

RP-Message-Reference 

Time Stamp 

TP-Service-center-time- stamp 

Information type 


Action result 

TP -Status 

Command object 


Sender address 

TP-Recipient address 


TP-Discharge time 

Service type 


Service subtype 


Data content type 


Message length 
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The following table lists the fields of each service that should be mapped in the 
direction of PP to FP for MMS-STATUS-RPY interworking to GSM SMS. (o) 
indicates an optional field. 


MMS 

GSM SMS 

GSM SMS 

MMS- 
STATUS-RPY 

RP-ACK 

RP-ERROR(SMS-SUBMIT- 
REPORT) 

Action type 

RP-Message-Type- 
Indicator 

RP or TP Message-Type- 
Indicator 

MMS 

sequence 

number 

RP-Message- 
Reference 

RP-Message-Reference 

Action result 

Value of 
"Successful" of 
MMS is used 

RP-Cause or TP -Failure- 
Cause 


This chapter gives an example when the MMS transparent service is used for 
GSM SMS interworking i.e. the GSM SM-TP layer messages are conveyd 
accross the air interface with MMS protocol. In this case the MMS is only* 
interworking with GSM SM-RP layer in the FP IWU as illustrated in figure 44. 

Message mappings between MMS and SM-RP layer 


Item 
No 

MMS MSG 

GSM SM-RP MSG 

Ref. 

Map 
Status 

Note 

1 

MMS-SEND 

RP-DATA 

9.3.2.1 

M 


2 

MMS-SEND-RPY 

RP-ERROR 

9.3.2.2 

M 


3 

MMS-SEND-RPY 

RP-ACK 

9.3.2.3 

M 


4 

MMS-COMMAND 

RP-SMMA 

9.3.2.4 

M 
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b 

M M b- U U M M AN U- 

RPY 

Kr-cKHUR 

Q O 1 C 

M 


6 

MMS-COMMAND- 
RPY 

RP-ACK 

9,3.2.6 

M 



MMS-SEND and RP-DATA 


Item 
No 

GSM SM-RP 
MSG 

MMS MSG 

DECT NWK MSG 

Coding 


RP-DATA 

MMS-SEND 

CC-INFO 


1 

nr-iviessags 

MCtion lype 

raciiiy oi iviivio 





< Action tvoe > 

"MMS-SEND" 

2 

RP-Message 
reference 

MMS Sequence 
number 

Facility or MMS 





^ IVl IVI o 

sequence nbr> 

MR 

3 


Message 

transmisson 

type 

Facilty or MMS 





<Transmisson 
type> 

"Encapsulated" 

4 


Content type 

Facilty or MMS 





< Content type> 

"GSM SMS" 

5 

RP- 

Originator 
address 

Sender address 

Calling party 
number 




< Number 
type> 

< Number type> 

Mapped from RP- 
OA 


wo 97/10684 


125 


PCT/GB96/02243 




< Number plan 
id> 

<Number plan 
id> 

Mapped from Rr- 
OA 



<CPN> 

<CPN> 

Mapped from RP- 
OA 

6 

RP- 

Destination 
address 

Receipient 
address 

Called party 
number 




< Number 
type> 

< Number type> 

Mapped from RP- 
OA 



< Number plan 
id> 

< Number plan 
id> 

Mapped from RP- 
OA 



< CPlSJ > 

< CPN > 

Mapped from RP- 
OA 

7 

RP-User- 
data 

User data 

IWU-TO-IWU 





<User protocol 
ID> 

GSM SM-TP 
message" 




< IWU-TO-IWU 
info> 

SM-TP message 


MMS-SEND-RPY and RP-ERROR 


Item 
No 

GSM SM-RP 
MSG 

MMS MSG 

DECT NWK MSG 

Coding 


RP-ERROR 

MMS- 
SEND-RPY 

CC-INFO 


1 

RP-Message 
Type 

Action 
type 

Faclity of MMS 
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< Action tvpe> 

"MMS-SEND- 
RPY 

2 

RP-Message 
reference 

MMS 

Sequence 

number 

Facility or MMS 





<MMS sequence nbr> 

mapped from 
RP-MR 

3 

RP-Cause 

Action 
result 

Facilty or MMS 





< Action result > 

mapped from 
RP-MR 

7 

RP-User- 
data 

Control 

IWU-TO-IWU 





<User protocol ID> 

"GSM SM-TP 
message" 




< IWU-TO-IWU info> 

SM-TP message 


MMS-SEND-RPY and RP-ACK 


Item 
No 

GSM SM-RP 
MSG 

MMS MSG 

DECT NWK MSG 

Coding 


RP-ACK 

MMS-SEND-RPY 

CC-INFO 


1 

RP-Message 
Type 

Action type 

Faclity of MMS 





< Action type> 

"MMS-SEND- 
RPY" 

2 

RP-Message 
reference 

MMS Sequence 
number 

Facility or MMS 
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^ IV>I IV/I o 

sequence nbr> 

mapped from RP- 
MR 

3 


Action result 

Facilty or MMS 





< Action result > 

"Successful" 


MMS-COMMAND and RP-SMMA 


Item 

iMO 

GSM SM-RP 

nil oo 

MMS MSG 

DECT NWK 
MSG 

Coding 


RP-SMMA 

MMS-COMMAND 

CC-INFO 


1 

RP-Message 
type 

Action type 

Facilty of MMS 





< Action type> 

"MMS- 
COMMAND" 

2 

RP-Message 
reference 

MMS Sequence 
number 

Facility or MMS 





<MMS 

sequence nbr> 

mapped from 
RP-MR 

3 


Command type 

Facilty or MMS 





< Command 
type> 

"Memory 
available" 


MMS-COMMAND-RPY and RP-ERROR 


Item 
No 

GSM SM-RP 
MSG 

MMS MSG 

DECT NWK MSG 

Coding 


RP-ERROR 

MMS- 
COMMAND 
-RPY 

CC-INFO 
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1 

RP-Message 
Type 

Action type 

Faclity of MMS 





< Action type> 

"MMS- 

COMMAND-RPY" 

2 

RP-Message 
reference 

MMS 

Sequence 

number 

Facility or MMS 





<MMS 

sequence nbr> 

mapped from RP- 
MR 

3 

RP-Cause 

Action 
result 

Facilty or MMS 





< Action result > 

mapped from RP- 
MR 

4 

RP-User 
data 

Control 
data 

IWU-TO-IWU 





<User protocol 
ID> 

"GSM SM-TP 
message" 




< IWU-TO-IWU 
info> 

SM-TP message 


MMS-COMMAND-RPY and RP-ACK 


Item 
No 

GSM SM-RP 
MSG 

MMS MSG 

DECT NWK MSG 

Coding 


RP-ACK 

MMS- 
COMMAND- 
RPY 

CC-INFO 


1 

RP-Message 
Type 

Action type 

Faclity of MMS 
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< Action type> 

"MMS- 

COMMAND- 

RPY" 

2 

RP-Message 
reference 

MMS 

Sequence 

number 

Facility or MMS 





<MMS sequence 
nbr> 

mapped from 
RP-MR 

3 


Action result 

Facilty or MMS 





< Action result > 

"Successful" 


The call establishment of the service may either be linked to the SM-CP layer 
primitives, to the SM-RP upperlayer primitives or it can be the internal task of 
DECT system to decide the timing of the call setup and release. 


In order to select the correct interworking unit and air interface profile in FP the 
following coding are used in the CC-SETUP message. 


Information 
element 

status 
in 

GAP 

Field within 
the information 
element 

Standard 
values within 
the field/IE 

Normative action/comment 

< <Portabl 
e 

identity > 
> 

M 



Coded as in GAP 

< < Fixed 
Identity > 
> 

M 



Coded as in GAP 

< < Basic 
service > > 

M 
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<CaII class > 

X X X X 

"iVlessaging call setup" 



< Basic 
service > 

1111 

"Other" The coding is 
defined by < <iwu 
attributes>> and < <call 
attributes > > 

< < Iwu- 
attributes 
> > 

1 






< Coding 
standard > 

0 1 

"Profile specific coding" 



< Profile ID> 

0 0 0 1 1 

" E profile " 



<NWK ID> 

0 0 

Ocete identifier 



< Network > 

0 0 11 

"GSM" 



< External 
service type> 

0 0 1 0 0 1 
1 

"GSM SMS" 



<HLC ID> 

1 0 

Octet identifier 



<HLC coding 
indicator > 

0 0 0 0 1 

"User protocol ID present" 



<User 

protocol ID> 

10 0 10 

"GSM Recommendation 
03.40, SM-TP messages 

[XX]" 

< <call 
attributes 
> > 

1 






< Coding 
standard > 

0 0 

DECT 



Network layer 
attributes 

0 110 0 

"DECT LRMS service 
profile (E data profile" 
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< <conne 
ction 
attriubtes 
> > 

1 






< < Number of 
bearer 
coding > > 

0 0 0 0 0 

"No-U-plane" in E profile 
case 


An example of the usage of service neaotation by using {CC-INFO} in 
DECT/GSM Interworkinq will now be described. 

1. PP originated call (see figure 45) 

Upon receipt of CC-SETUP-ind with < <IWU-ATTRIBUTES> > containing the 
value "Connection exchange parameter negotiation" in the << Negotiation 
indicator field > > from the CC entity the FP IWU will reject the request 
immediately issuing MNCC-REJECT-req with << Release reason >> Hex 07 
"Negotiation not supported" if the FP cannot support Extended exchange 
attributes negotiation. 

If the FP can support the Extended exchange parameter negotiation the FP IWU 
will map the << IWU- ATTRIBUTES > > information element contained in {CC- 
SETUP} message to the GSM << BEARER CAPABILTY>> element of GSM 
{Setup} message. 

1) Upon receipt of the GSM {Call proceeding} message the FP IWU will send 
DECT {CC-CALL-PROCEEDING} message to PP. If the {Call proceeding 
message} contained << Bearer capabiliity > > information element the new 
values of the << Bearer capability >> will be mapped into the <<IWU- 
ATTRIBUTES> > information element of the DECT < < CC-INFO > > message. 
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If no {Call proceeding} message is received or it does not contain < < BEARER 
CAPABILITY >> infornnation elennent the service parameters have been 
accepted by the MSC IWF and no mapping between the << BEARER 
CAPABILITY > > and < < IWU-ATTRIBUTES> > information element is needed. 

2. PR terminated call (see figure 46) 

Upon receipt of CC-SETUP-ind with < <IWU-ATTRIBUTES> > containing the 
value "Extended exchange parameter negotiation" in the << Negotiation 
indicator field >> from the CC entity the PP IWU will reject the request 
immediately issuing MNCC-REJECT-req with << Release reason >> Hex 07 
"Negotiation not supported" if the PP cannot support Extended exchange 
attributes negotiation. 

If the PP can support the Extended exchange parameter negotiation the PP IWU 
will add the new desired attributes values to the < <IWU-ATTRIBUTES> > 
information element of the {CC-INFO} message. The {CC-INFO} message can be 
sent only following by {CC-ALERTING} message. 

2) and 3). It is then the responsibility of the FP IWU to suspend the submission 
of the {Call confirm} and {Alerting} message towards the GSM network until 
the new desired values have been received in the {CC-INFO} message. The new 
values in the < < IWU-ATTRIBUTES> > information element of the {CC-INFO} 
message are mapped into the GSM BEARER CAPABILTY element of {Call 
Confirmed} message. Other mappings between {CC-CONNECT} and {Connect} 
message as well as {CC-ALERTING} and {Alerting} messages are done as 
described in ETS 300 370 FINAL DRAFT prETS 300 370, Radio Equipment and 
Systems (RES); Digital European Cordless Telecommunications/Global System 
for Mobile communications (DECT/GSM) inter-working profile. Access and 
mapping (Protocol/procedure description for 3,1 kHz speech service). European 
Telecommunications Standards Institute. September 1994. 98 pages. 
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The PP IWU shall not send the {CC-INFO} message after {CC-ALTERTING} 
message if it agrees with the service parameters proposed in the {CC-SETUP} 
message. If {CC-CONNECT} message is received as a response to the {CC- 
SETUP} message the proposed parameters have been accepted. 
If the PP IWU accepts the parameters proposed by MSC the call establishment 
proceeds as defined in ETS 300 370. 

The present invention includes any novel feature or combination of features 
disclosed herein either explicitly or any generalisation thereof irrespective of 
whether or not it relates to the claimed invention or mitigates any or all of the 
problems addressed. 

In view of the foregoing description it will be evident to a person skilled in the 
art that various modifications may be made within the scope of the invention in 
particular the invention is applicable for use under other protocols including 
Wireless Customer Premises Equipment (WCPE) and Personal Handyphone 
System (PHS). 
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CLAIMS 

1 . A messaging system for communicating a message between a first 
communications unit having a first messaging entity and a second 
communications unit having a second messaging entity, each messaging entity 
comprising: 

a messaging call control means for establishing a messaging 
communications link with the other messaging entity; and 

a messaging means for, once the messaging communications link has 
been established, exchanging messaging information with the said other 
messaging entity. 

2. A messaging system as claimed in claim 1, wherein the messaging call 
control means is capable of operating under the control of the messaging 
means. 

3. A messaging system as claimed in claim 2, wherein the messaging entity 
is capable of receiving data from and transmitting data to the application layer 
of a communication protocol. 

4. A messaging system as claimed in claim 3, wherein the messaging entity 
constitutes a virtual layer between the application layer and the network layer 
of the communication protocol. 

5. A messaging system as claimed in any preceding claim, wherein the 
messaging information includes header data and user data associated with the 
message. 

6. A messaging system as claimed in claim 5, wherein the header data and 
the user data include data defining a message sequence number of the 
message. 
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7. A messaging system as claimed in any preceding claim, wherein the 
messaging communications link uses two links. 

8. A messaging system as claimed in claim 7, wherein one of the links 
carries header data and the other link carries user data. 

9. A messaging system as claimed in chaim 8, wherein the said one link 
operates through a C-plane and the other link operates through a U-plane. 

10. A messaging system as claimed in any preceding claim, wherein the 
messaging communications link is made by means of a radio link between the 
first communications unit and the second communications unit. 

11. A messaging system as claimed in claim 10, wherein the first 
communications unit is a portable part and the second communications unit is a 
fixed part. 

12. A messaging system as claimed in claim 10 or 11, wherein the radio link 
operates according to the DECT, WCPE or PHS protocols. 

13. A messaging system substantially as herein described with reference to 
the accompanying drawings. 

14. A messaging method for communicating a message between a first 
communications unit and a second communications unit, the first 
communications unit having an application layer, a messaging entity and a 
network layer, the method comprising the steps of: 

transmitting a signal from the application layer to the network layer as a 
means of establishing a call; 

exchanging messaging information between the application layer and the 
network layer by way of the messaging entity to communicate the message; 
and 
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transmitting a signal from the application layer to the network layer as a 
means of disconnecting the call. 

15. A messaging method for communicating a message between a first 
communications unit and a second communications unit, the first 
communications unit having an application layer, a messaging entity and a 
network layer, the method comprising the steps of: 

transmitting a signal from the messaging entity to the network layer as a 
means of establishing a call; 

exchanging messaging information between the application layer and the 
network layer by way of the messaging entity to communicate the message; 
and 

transmitting a signal from the messaging entity to the network layer as a 
means of disconnecting the call. 

16. A messaging method substantially as herein described with reference to 
the accompanying drawings. 
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15/ 


iFax 


1' Short messages (SMS) 


MHS command/ 
information set 


"Mapping and"" 
data fIovv(Fax) 

U-plane 


DLC 


Mapping(Fax/SM^) I 
and data flow (SM^S) j 

C-jilane 

T 


NWK 
DLC 


MAC 
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DECT NWK i CC 


DECTDLC ILAPU 
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M-MMS M- 


MMS-SEND 


MMS-SEND-RPY 
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M-MMS M- 


MMS-RECEIVE 
MMS-RECEIVE-RPY 
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M-MMS M-MMS 


MMS-COMMAND 


MMS-COMMAND-RPY 
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M-MMS M-M 


MMS-STATUS 
MMS-STATUS-RPY 
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CC-SETUP 
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CC-SERVICE-CHANGE 


CC-SERVICE-ACCEPT 


CC-SERVICE-CHANGE 
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CC-RELEASE 


CC-RELEASE-COM 
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Comments 


Profile attributes: 
Profile attributes: 

Network attributes: 
Network attributes: 

Network attributes: 

LLC attributes: 

LLC infonnation transfer 
attributes: 

LLC infonnation transfer 
attributes: 

LLC infonnation transfer 
attributes; 

LLC infonnation transfer 
attributes: 

LLC infonnation transfer 
attributes: 

LLC infonnation transfer 
attributes: 

LLC access attributes: 

LLC access attributes: 
LLC access attributes: 


LLC access attributes: 
LLC access attributes: 
LLC transparent U-pIane 
attributes: 

LLC transparent U-pIane 
attributes: 

LLC transparent U-plane 

attributes: 

HLC attributes: 

HLC attributes: 

HLC attributes: 

HLC attributes; 

HLC attributes: 

HLC attributes: 

QoS attributes 


Bit 


0 

« rWU-ATTRIBUTES » 

Length of Contents (L) 

0/1 

Coding 

Profile 

0/1 

Negotiation 
indicator 

Spare 

0/1 

Nwk Id. 1 Externa 1 coiuiection type 

0/1 

Network 

TE-network 
interface 

0/1 

External service type 


LLC id. 

LLC coding indicator 

U/ 1 

Spare 

Lifonnaiion transter capability 

n/ 1 

U/ 1 

Trans mode 

Infonnation transfer rate 

it/ 1 

Unit Ualo 

Rate nuiltiplicr 

U/ 1 

Slniclurc 

Con tig. 

Establ, 

0/1 

Synunetry 

Infonnation transfer rate 
{Dest=> Oriainator) 

0/1 

Unit Rale 

Rate multiplier 
CDest=> Originator) 

0/1 

Rate adapt. 

Signalling access 
protocol 

S/A 

Neg. 

0/1 

User rate 

0/1 

Luenn. rate 

NIC 
on 
TX 

NIC 
on 
RX 

F-C 
tx 

F-C 
rx 

0 

0/1 

Stop bits 

Data bits 

Parity 

1 
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